> 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
You would block interrupt handling for all devices that are sharing the
IRQ with your broken code.
> 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.
The fact that Linux does not implement a interrupt priority scheme makes
such a scheme broken for Linux but does not implies that this scheme is so
for every O/S. When the actual hardware priorities fits the best priority
hierarchy for the reality, then it is good, IMO.
> 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.
The PC hardware is crap, but seems to be very permissive since it is used
by numerous different O/Ses. That's not the case of proprietary hardware
that has generally been designed for a single O/S.
> 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.
Yes, being portable implies that you have to be reasonnably good for all
architectures you support. The fact that an architecture does not fit
Linux design does not imply that it is bad, neither than Linux is bad.
You cannot be the best in all situations.
> And btw, for people worrying about SA_INTERRUPT - I'll probably just make
> it go away. It doesn't have any real redeeming features.
Why?
SA_INTERRUPT + SHIRQ made problems sharing IRQs between the SCSI
sub-system and the network sub-system for years. This does not mean that
SA_INTERRUPT is essentially bad.
You can try to get perfect, but you will never be so.
Regards,
Gerard.
-
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/