Clustered interrupt blocking is just horrible, and not a portable thing to
depend on anyway.
Note that Linux already has _exactly_ the right semantics for interrupt
handling:
- when an interrupt handler is in process, that interrupt handler is
single-threaded. All other interrupts can still happen.
This means that in a perfect world we could just do all the network packet
handling inside the network device interrupt, and everybody would be
happy, because we'd still have good interrupt response times for
everything else - because we wouldn't be blocking anything else by running
inside the interrupt. We might still want to throttle the rate to make
sure we don't starve normal processing, but basically we should still be
ok.
However, there are just too many broken machines out there that do not
support the above (obviously correct) semantics very well. A lot of
hardware has a notion of interrupt priorities, and a "higher-priority"
interrupt will block all lower-priority interrupts. As a result, even
though the Linux approach to interrupts is supposed to be simple and
clean, hardware considerations still mean that we do _not_ want to spend
much time inside the interrupt handler.
This, btw, is not a PC hardware issue. We can use both the IO-APIC and the
older PIC essentially without having to care about the priorities by doing
a "mask+ack" operation at the beginning of the interrupt handling. But
there are other platforms where you cannot avoid the prioritization.
And that is why we need to queue the thing, even though queueing does add
overhead, and allows us to get interrupts faster than we can process them.
I agree completely with you on that point, it's just that we're limited by
being portable.
And btw, for people worrying about SA_INTERRUPT - I'll probably just make
it go away. It doesn't have any real redeeming features.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/