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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
