linux-kernel - Re: [PATCH] i386 IOAPIC: de-fang IRQ compression

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <32209efe0712051548n72f60b0eofa130f28701ca77@mail.gmail.com>
Date:	Wed, 5 Dec 2007 15:48:28 -0800
From:	"Natalie Protasevich" <protasnb@...il.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	"Len Brown" <lenb@...nel.org>, "Andi Kleen" <ak@...e.de>,
	"Ingo Molnar" <mingo@...hat.com>,
	"Thomas Gleixner" <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] i386 IOAPIC: de-fang IRQ compression

On Dec 5, 2007 3:25 PM, Eric W. Biederman <ebiederm@...ssion.com> wrote:
>
> "Natalie Protasevich" <protasnb@...il.com> writes:
>
> > On Nov 27, 2007 10:21 PM, Len Brown <lenb@...nel.org> 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/