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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
