Andi Kleen <ak@xxxxxxx> writes: >> Allowing the kernel to work on big machines without complicated >> and error prone irq remapping logic. > > How much memory does this use by default? If it's much there should > be at least a CONFIG_* to make it smaller. If you don't build a generic kernel and are not a big way smp you only get 200 IRQs so it is less. Otherwise it is either 1024 or NR_CPUS*32 depending on the subarch we compile. The limits are actually unchanged from what we are doing today. I'm in the final stages of figuring out how to kill the stupid irq_desc array which should make all the memory consumption worries go away but that is a little ways off, and I'm putting real bug fixes ahead of that work. Basically this is just a back port from x86_64 without the complication of the per cpu vector logic. So if we run into any issues I missed before this reaches a stable kernel we can just copy the fix from x86_64 where we have been doing this for a while. So in short the existing CONFIG_ options should give us the control we need, and before it becomes any kind of an issue I intend to completely remove the compile time limit and make it dynamic. 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
