Messages in this thread | | | Date | Thu, 15 Jan 2004 17:40:54 -0500 (EST) | From | Zwane Mwaikambo <> | Subject | Re: [PATCH] 2.6.1-mm2: Get irq_vector size right for generic subarch UP installer kernels |
| |
On Thu, 15 Jan 2004, James Cleverdon wrote:
> > In my opinion we should be breaking after we've exceeded the maximum > > external vectors we can install. This will of course mean less than > > the number of RTEs. James have you actually managed to use the devices > > connected to the high (over ~224) RTEs? > > No, I haven't exceeded the available vectors, but wli has on a large NUMA-Q > box.
Yes i believe the 8 node NUMA-Qs do this easily.
> The x440 and x445's problems are pre-reserving lots of bus numbers in the > BIOS, more than one per PCI slot. They must be anticipating PCI cards with > bridge chips on them.
For some odd reason i thought we had dynamic allocated MP busses.
> I believe that the reason for irq_vector being so large is to allow IRQ (and > eventually vector) sharing. The array is to map from RTE to vector.
What i'm trying to say is that the current code will behave badly when you actually do encounter a system with that many RTEs, the actual array being that large isn't a problem, the problem is what's going on in assign_irq_vector() and later on with set_intr_gate(). By that i mean;
- The interrupt[] stub in entry.S is written with 256 irqs in mind so it wouldn't be able to pass higher irq numbers to do_IRQ in it's current state.
- "Wrapping" in assign_irq_vector means that you overrite previously assigned vector entries in the IDT with whatever interrupt[irq] you happen to be installing at the time. To avoid this you should not be allowing more than ~224 vectors to be handed out by assign_irq_vector(), with the patch and the current code, this is possible.
Lastly i think we should avoid sharing vectors, going the IA64 route and setting up irq handling domains of sorts would allow for easier scaling both up and down.
Thanks, Zwane - 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/
| |