Messages in this thread | | | Date | Mon, 07 Apr 2003 19:31:39 -0700 | From | "Martin J. Bligh" <> | Subject | Re: [PATCH][2.5] avoid scribbling in IDT with high interrupt count. |
| |
> My patch skips irq numbers > NR_IRQS and simply return error when we run > out of vectors, although mainline doesn't assign duplicates and cause > collisions, it does waste vector space. e.g. for a system with > NR_IRQS = 224 we have 23 vectors free, 0 collisions and 167 useable irqs > and assign_irq_vectors states that we're out of vectors. > >> In other words, I'm wondering if this simpler patch wouldn't be sufficient >> instead? >> >> Can you please test this, and re-submit (and if you can explain why your >> patch is better, please do so - I have nothing fundamentally against it, I >> just want to understand _why_ the complexity is needed). > > Your patch booted the system but there are vector collisions resulting in > lost irq routing when we program the IOAPIC with the duplicated vector. So > with your patch and NR_IRQS = 224 we have 1 vectors free (0x80), 34 collisions > and 225 irqs. However that isn't a fault of your patch but a fault with > the NR_IRQS definition. This is what the vector space looks like on i386 > at present. > > 0________0x31__________________________0xef____________0xff > system io interrupts resvd vectors > > 0xef - 0x31 = 190 useable io interrupt vectors > > So perhaps we should, apply your patch, add a NR_IRQ_VECTORS define > and also add commentary in irq_vectors.h how does the following look? I > had to readd the NR_IRQS checks to protect against overrunning NR_IRQS sized > arrays and i added nr_assigned to track how many vectors were allocated so > taht we can bail out when we're out. > > Patch has been tested on a 320 interrupt system and had a maximum useable > irq line of 211 (ethernet).
We're still allocating interrupts to a bunch 'o stuff that isn't actually being used ... I'd prefer it if we could change that, and allocate them as they're actually used, rather than (what I believe is) still a fixed number per IO-APIC. Is there some smart way to do that?
If not, the overflow protection is still (obviously) a good thing to do.
M.
- 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/
| |