On Dec 5, 2007 3:25 PM, Eric W. Biederman <[EMAIL PROTECTED]> wrote: > > "Natalie Protasevich" <[EMAIL PROTECTED]> writes: > > > On Nov 27, 2007 10:21 PM, Len Brown <[EMAIL PROTECTED]> wrote: > >> commit c434b7a6aedfe428ad17cd61b21b125a7b7a29ce > >> (x86: avoid wasting IRQs for PCI devices) > >> created a concept of "IRQ compression" on i386 > >> to conserve IRQ numbers on systems with many > >> sparsely populated IO APICs. > >> > >> The same scheme was also added to x86_64, > >> but later removed when x86_64 recieved an IRQ over-haul > >> that made it unnecessary -- including per-CPU > >> IRQ vectors that greatly increased the IRQ capacity > >> on the machine. > >> > >> i386 has not received the analogous over-haul, > >> and thus a previous attempt to delete IRQ compression > >> from i386 was rejected on the theory that there may > >> exist machines that actually need it. The fact is > >> that the author of IRQ compression patch was unable > >> to confirm the actual existence of such a system. > > > > Those systems did exist (and still exist actually). They used over 200 > > irqs sometimes and with "normal" IRQ allocation they were failing even > > before reaching half of their I/O configuration. So simple removal > > wouldn't work for those, dynamic allocation sure would. They "scrolled > > off the topic" though because new generations of such machines are not > > 32 bit anymore. So the author didn't actually object :) it was the > > other users of large 32 bit platforms that did. > > Natalie. Did they just have over 200 irqs/gsis or did they actually > use over 200 irqs? >
I think we counted them in the order of 1400 external IRQs (actual ioapics/slots plus possible on-card bridges), and yes numbers for used IRQs were close to 250. Actual customer configurations could've big bigger, I don't have such data. > In particular is a large NR_IRQS plus dynamic vector allocation > sufficient for all cases you know about? Yes, since x86_64 boxes never had a problem once dynamic vectors were incorporated. > > Eric > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/