Bug#491309: NR_CPUS in debian linux-images

[Mike Travis <travis@sgi.com>]

maximilian attems wrote:
> hello
> 
> after getting an irc query and bug report on our currently set number of
> cpu for the upcoming lenny release:
> /boot/config-2.6.26-1-amd64:CONFIG_NR_CPUS=32
> 
> -> http://bugs.debian.org/491309
> 
> we came to this issue:
> 10:13 <waldi> 1345623 3148364  417112 4911099  4aeffb x86_64-255/vmlinux
> 10:13 <waldi> 1339887  380556  273880 1994323  1e6e53 x86_64-32/vmlinux
> 10:13 <waldi> only change is the number of cpus *gna*
> 
> 10:16 <waldi> struct irq_cfg irq_cfg[NR_IRQS] __read_mostly = {
> 10:18 <waldi> yeah, 2.5MiB just for the interrups
> 10:19 <waldi> #define NR_IRQS (256 + (32 * NR_CPUS))
> 10:29 <waldi> and because some parts have static initializers, it can't be moved
>  into the bss section
> 
> the debian installer cares about the image size.
> 
> thanks for your input, as i see that you do the 4k cpu work on 2.6.27.
> 

Hi,

Yes, we are aiming at having NR_CPUS=4096 as the default for distros using
2.6.27.  The above structure is by far the biggest memory hog (along with the
companion irq_desc[]) and we've targeted the next release to go to dynamically
allocated irq's (which btw, hopefully will have NR_CPUS=16384.)  The problem
with irq_cfg is that each element contains a cpumask_t field so growing NR_CPUS
causes an exponential increase.

You could look at the 2.6.27 version of include/asm-x86/irq_vectors.h to see
how NR_IRQ's is somewhat lessened (at least from a NR_CPUS=4096 perspective.)

Thanks,
Mike