Re: [(repost) git Patch 1/1] avoid IRQ0 ioapic pin collision

[ebiederm@xmission.com (Eric W. Biederman)]

Andi Kleen <ak@suse.de> writes:

>> >- Modify do_IRQ to get passed an interrupt vector# from the
>> >  interrupt vector instead of an irq number, and then lookup
>> >  the irq number in vector_irq.  This means we don't need
>> >  a code stub per irq, and allows us to handle more irqs
>> >  by simply increasing NR_IRQS.
>> 
>> isn't the vector number already on the stack from
>> ENTRY(interrupt)
>> 	pushl $vector-256
>
> Yes - and interrupts/vectors are currently always identical. 

No.  At best there is a fixed offset.  They can't be
identical because the first 32 vectors are reserved,
for processor exceptions.  

Beyond that the kernel would not need the vector_irq and irq_vector
arrays if they were always identical, or even if they were one to one.

If you look at assign_irq_vector you will see that by default we
allocate every 8th vector.  Looking at the comment in
init_IO_APIC_traps() this seems to be because we want to avoid
apic bugs with multiple interrupts of the same priority.
Although why we skip 8 instead of 16 is beyond me.

> If we go
> to per CPU IDTs I suspect the stubs will just need to be generated
> at runtime and start passing interrupts.

If we can generate the stubs at run time that will remove my
biggest problem with them, that we can't easily make the number
of stubs track NR_IRQS.  Not needing an extra table lookup is
certainly desirable, and probably worth the extra 4-8 bytes that a stub
is larger that a per cpu table entry.

Although now that I think about it, using some assembler macros
instead of cpp macros could probably solve the problem more easily
than generating the stubs at runtime.  I think the worst case is
256 cpus * 32 irqs per cpu * 10 bytes per stub = 80K.

At 8 cpus we are about where we are now.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/