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

[Eric W. Biederman]

Len Brown <lenb@xxxxxxxxxx> writes:

> On Wednesday 05 December 2007 04:48, Ingo Molnar wrote:
>> 
>> * Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
>> 
>> > On Tue, 4 Dec 2007 13:26:49 +0100
>> > Ingo Molnar <mingo@xxxxxxx> wrote:
>> > 
>> > > * Len Brown <lenb@xxxxxxxxxx> wrote:
>> > > 
>> > > >     So while the irq compression code on i386 should really
>> > > >     be deleted -- even before merging the x86_64 irq-overhaul,
>> > > >     this patch simply disables it on all high volume systems
>> > > >     to avoid problems #1 and #2 on most all i386 systems.
>> > > >     
>> > > >     A large system with pin numbers >=64 will still have compression
>> > > >     to conserve limited IRQ numbers for sparse IOAPICS.  However,
>> > > >     the vast majority of the planet, those with only pin numbers < 64
>> > > >     will use an identity GSI -> IRQ mapping.
>> > > >     
>> > > >     Signed-off-by: Len Brown <len.brown@xxxxxxxxx>
>> > > 
>> > > thanks for the patch and the extensive description. I've applied this to 
>> > > x86.git.
>> > 
>> > Len applied it to his tree too.
>> 
>> Len, i think this belongs into x86.git a bit more (especially with the 
>> unification activities going on all around the tree) - do you agree? 
>> Andrew, i'd suggest to apply a reverted patch to between git.acpi and 
>> git.x86 until this gets sorted out.
>
> Sure.
> I'm re-basing my test branch right now and can exclude this one
> since it is in x86.git. (and yes, I'm interested in unifying mpparse_*.c some
> day)
>
> yes, your understanding is correct -- this is not urgent 2.6.24 material,
> it is just a 'regular patch':-)
>
> Re: making the VIA part into dead-code
> I had avoided that originally because I was going to nominate
> this patch for the highest check-in-comment length/code-change ratio
> But once I went over 1 line I blew the budget;-)
>
> Eric,
> What do you suggest we do with NR_IRQS on i386 so that we
> can delete the compression code entirely?
>
> thanks,
> -Len

Attached below is my patch from last time I was looking at this
problem, it doesn't quite apply but it is gives a good idea of where
I think we should go.

For the current 64bit kernel we do have a point where if we run out
of vectors we just can't use the irqs.  Because that point is
about 192*nr_online_cpus() we never hit it in practice.

If we just rip out the vector irq compression logic (without
implementing the per cpu vector logic) we will theoretically
have systems that will not run out of vectors and so some of their
irqs (50?) won't work, but it is likely those systems will still boot.

Unless there are really nasty ioapic bugs on that don't show up on
the 64bit systems we should be able to move the  per cpu vector
logic onto the 32bit side as well now that we understand what needs
to happen.  I didn't want to do the port until we had stabalized
things on the 64bit side, which largely we seem to have managed.

So as long as we are going to move the per cpu vector logic eventually
to the 32bit kernels I don't think we will have a problem if we
increase NR_IRQs, then kill the compression, and then get around to
implementing the per cpu vector logic.