It appears that the primary difference between your patch and Eric's
is that you estimate the number of IRQ's required based on the number
of cpus present, while Eric's patch grows the list based on the IRQ's
being requested. For soon to be "power" desktop systems (say dual 8 core
Nahalem's w/HT), you're reserving IRQ's for 32 cpus on a system which
probably has one I/O bus (or maybe two). A dual socket Larabbee system
will have 256 cpus. An SGI UV system has more of a "building block"
approach, where you can grow all three (cpus, memory, I/O) independently.
One other very nice feature of Eric's approach is that the new "IRQ"
struct being requested can be created in "node local" memory, cutting
down significantly the number of "cross node" accesses.
Plus, I still like Ingo's suggestion to not change NR_IRQS ==> nr_irqs.
CONFIG_ARCH_HAS_DYNAMIC_IRQS spells out exactly what NR_IRQS means.
(Even more accurate would be CONFIG_ARCH_HAS_DYNAMIC_NR_IRQS.)
The DEFINE_DYN_ARRAY could be the following. (Changing general purpose
DYN_ARRAY to specifically purposed IRQ_ARRAY.)
#ifdef CONFIG_ARCH_HAS_DYNAMIC_IRQS
#define DEFINE_IRQ_ARRAY <new variable irq array [or list] definition>
#else
#define DEFINE_IRQ_ARRAY <old static irq array>
#endif
For the immediate problem, unraveling the code merge back to IRQ's based
on NR_IOAPICS would seem to be the least intrusive.
Thanks,
Mike
--
