summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2008-08-25 14:15:38 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2008-08-25 14:15:38 -0700
commitd25e26b61d59370eee8b7f2634641eb0fa76e952 (patch)
tree51356ee7102416d8f61a55b8447e7f59279347f5
parent426e1eafdbd1d1349c852a2b90c7f20879d52ed2 (diff)
downloadop-kernel-dev-d25e26b61d59370eee8b7f2634641eb0fa76e952.zip
op-kernel-dev-d25e26b61d59370eee8b7f2634641eb0fa76e952.tar.gz
[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>
-rw-r--r--arch/x86/Kconfig30
1 files changed, 8 insertions, 22 deletions
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 68d91c8..ed92864 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -577,35 +577,29 @@ config SWIOTLB
config IOMMU_HELPER
def_bool (CALGARY_IOMMU || GART_IOMMU || SWIOTLB || AMD_IOMMU)
+
config MAXSMP
bool "Configure Maximum number of SMP Processors and NUMA Nodes"
- depends on X86_64 && SMP
+ depends on X86_64 && SMP && BROKEN
default n
help
Configure maximum number of CPUS and NUMA Nodes for this architecture.
If unsure, say N.
-if MAXSMP
-config NR_CPUS
- int
- default "4096"
-endif
-
-if !MAXSMP
config NR_CPUS
- int "Maximum number of CPUs (2-4096)"
- range 2 4096
+ int "Maximum number of CPUs (2-512)" if !MAXSMP
+ range 2 512
depends on SMP
+ default "4096" if MAXSMP
default "32" if X86_NUMAQ || X86_SUMMIT || X86_BIGSMP || X86_ES7000
default "8"
help
This allows you to specify the maximum number of CPUs which this
- kernel will support. The maximum supported value is 4096 and the
+ kernel will support. The maximum supported value is 512 and the
minimum value which makes sense is 2.
This is purely to save memory - each supported CPU adds
approximately eight kilobytes to the kernel image.
-endif
config SCHED_SMT
bool "SMT (Hyperthreading) scheduler support"
@@ -996,17 +990,10 @@ config NUMA_EMU
into virtual nodes when booted with "numa=fake=N", where N is the
number of nodes. This is only useful for debugging.
-if MAXSMP
-
config NODES_SHIFT
- int
- default "9"
-endif
-
-if !MAXSMP
-config NODES_SHIFT
- int "Maximum NUMA Nodes (as a power of 2)"
+ int "Maximum NUMA Nodes (as a power of 2)" if !MAXSMP
range 1 9 if X86_64
+ default "9" if MAXSMP
default "6" if X86_64
default "4" if X86_NUMAQ
default "3"
@@ -1014,7 +1001,6 @@ config NODES_SHIFT
help
Specify the maximum number of NUMA Nodes available on the target
system. Increases memory reserved to accomodate various tables.
-endif
config HAVE_ARCH_BOOTMEM_NODE
def_bool y
OpenPOWER on IntegriCloud