Andi Kleen <ak@xxxxxxx> 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-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
