> 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/
This archive was generated by hypermail 2b29 : Mon Apr 07 2003 - 22:00:34 EST