Passing a pointer to an identification function would be one sensible
approach on IRQ resource allocation. Then, the driver IRQ handler would
execute knowing a valid event was generated, and of interest to it, rather
than the IRQ handler executing when the event _may_ be of interest to it.
IMHO, this would also ensure that all drivers dealt with the issue of IRQ
sharing, since I'm sure it's quite easy to assume hardware won't share IRQs
(which was more the case a few years ago) with less PCI slots, etc.
The 'Boot to PnP OS' option in Award BIOS setups seems to eliminate (or
reduce) IRQ sharing.
Does it do this by manipulating the IRQ routing tables in the chipset? (I
think it does, but I'm not sure).
It so, then one optimisation could be to re-route IRQs at boot-time, so all
devices are on disjoint IRQ lines. This would introduce the possibility
that, if the kernel knew there was only one device sitting on an IRQ, it
could bypass the 'strict' checking function mentioned earlier. Since this is
dealt with in the bottom-half handler, I suppose it's not as much of an
issue, but I like the idea of the kernel tweaking the IRQ routing table to
it's advantage. Even if the checks were still in place, there would only be
the minimum required checks.
Just a side note:
All current and previous Intel chipsets (440BX, 440ZX, 430TX, et al) support
only four request and grant pairs (pins to control bus-master operation),
and hence interrupts. I've never been able to allocate more than 4 IRQs to
PCI cards, without the extra use of IRQ routing. Things get worse when you
have 5 PCI slots, 1 AGP slot, extra onboard controllers (eg sound and
ethernet). Of course, more advanced PCI cards can request more than 1 IRQ
each (INT #A and INT #B) (oh dear), so having an appropriate treatment of
IRQ handling _now_ will save time in the future. If more of the generic
handling is in the kernel, then when chipset architecture slowly evolves (eg
the new Camino 820 CX chipset), code like drivers don't need to be altered
so much.
It's not too bad in the case for GPL drivers in the kernel, but
otherwise....
(blah, blah) The Intel 820CX (Camino) chipset due for release on Sep 27th
supports 6 GNT/REQ pairs, so things need to be catered for. The IA{32,64}
chipsets could incorporate significant changes. I can see 16 IRQ lines being
somewhat of a limitation when you're building a large, scaleable server,
even though they can be shared.
Does this make any sense?
Dan
__________________________
Daniel J Blueman - daniel.j.blueman@stud.umist.ac.uk
Undergraduate - BSc Computing Science
UMIST - Manchester
-
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/