> When you multiply 11520 * 1.54 usecs, you find that on a Pentium 100,
> 17.7% of your CPU time is spent in the interrupt system's overhead.
it's 1.7% actually ...
> I suspect that Linus is right, though, that by optimizing the interrupt
> return path so that it is separate from the system call return path will
> be a win. [...]
sorry my point was not properly made. I should have shown a 'fast'
interrupt handler as well, and show that it has about the same amount of
(very small) 'offset latency' as a slow interrupt handler.
_plus_, on ISA, and even on PCI we have ring-switch and IRQ dispatching
latency, which is at least ~3 usecs on ISA [the CPU does _nothing_ during
that]. So i should have said the following:
- the assembly differences between the BUILD_FAST_IRQ and BUILD_IRQ
macros are lost in the noise. It's the number of interrupts and the
number of "heavy" actions taken that makes the difference.
and to repeat the IMHO correct conclusion: we should "unify" all the
interrupt paths, and merge the two "extremes" (all action and zero action)
into this new scheme incrementally. This also enables intermediate (smart)
interrupts.
the point in smart interrupts would be the separation of event sources.
Ie. even if there is a bottom half handler activated by another event, we
only "notice" our own per-event bottom half handler. Thus no irq can "get
in the way" of other interrupts doing some clever event-clustering or
whatever technique?
-- mingo