]> pilppa.com Git - linux-2.6-omap-h63xx.git/commit
[x86] Clean up MAXSMP Kconfig, and limit NR_CPUS to 512
authorLinus Torvalds <torvalds@linux-foundation.org>
Mon, 25 Aug 2008 21:15:38 +0000 (14:15 -0700)
committerLinus Torvalds <torvalds@linux-foundation.org>
Mon, 25 Aug 2008 21:15:38 +0000 (14:15 -0700)
commitd25e26b61d59370eee8b7f2634641eb0fa76e952
tree51356ee7102416d8f61a55b8447e7f59279347f5
parent426e1eafdbd1d1349c852a2b90c7f20879d52ed2
[x86] Clean up MAXSMP Kconfig, and limit NR_CPUS to 512

This fixes a regression that was indirectly caused by commit
1184dc2ffe2c8fb9afb766d870850f2c3165ef25 ("x86: modify Kconfig to allow
up to 4096 cpus").

Allowing 4k CPU's is not practical at this time, because we still have a
number of places that have several 'cpumask_t's on the stack, and a
4k-bit cpumask is 512 bytes of stack-space for each such variable.  This
literally caused functions like 'smp_call_function_mask' to have a 2.5kB
stack frame, and several functions to have 2kB stackframes.

With an 8kB stack total, smashing the stack was simply much too likely.
At least bugzilla entry

http://bugzilla.kernel.org/show_bug.cgi?id=11342

was due to this.

The earlier commit to not inline load_module() into sys_init_module()
fixed the particular symptoms of this that Alan Brunelle saw in that
bugzilla entry, but the huge stack waste by cpumask_t's was the more
direct cause.

Some day we'll have allocation helpers that allocate large CPU masks
dynamically, but in the meantime we simply cannot allow cpumasks this
large.

Cc: Alan D. Brunelle <Alan.Brunelle@hp.com>
Cc: Mike Travis <travis@sgi.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
arch/x86/Kconfig