> #2: You got it right. The hw is designed to generate a fewer # of
> interrupts, since the information necessary is available in other
> means, and there is a lot of time saved by not taking the interrupt.
point is, there is no time saved by not taking the interrupt. In fact it's
slightly more expensive to use smp_call_function() instead of getting the
proper hardware interrupts. (because there is some setup cost of inter-CPU
APIC interrupts, and also you have to load-balance manually.)
the IRQ latency itself does not show up as lost CPU time on modern IRQ
delivery systems - while the IRQ latency is around 5-10 microseconds, the
true 'null interrupt cost' is only around 1-3 microseconds on 8-way
systems. And by generating cross-CPU interrupts for smp_call_function()
there are almost no savings anyway - they are normal interrupts and have
similar IRQ entry overhead as hardware-IRQs.
so it's almost always the better idea to use multiple interrupts if there
are multiple, more or less orthogonal devices. There might be cases where
it's the best solution to keep a single IRQ source (eg. hw simplicity, or
conserving IRQ space) - but almost never for performance reasons,
software-driven IRQ distribution is not going to be more efficient than a
hardware-based one.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/