summaryrefslogtreecommitdiffstats
path: root/arch/sparc64/Kconfig
diff options
context:
space:
mode:
authorDavid S. Miller <davem@sunset.davemloft.net>2007-05-26 01:14:43 -0700
committerDavid S. Miller <davem@sunset.davemloft.net>2007-05-29 02:49:49 -0700
commit22adb358e816ce6aa0afb231ae9d826b0bddc8b0 (patch)
tree6f9886bf5b4e5c916c72d8d5733211813873c5fc /arch/sparc64/Kconfig
parent5cbc30737398b49f62ae8603129ce43ac7db1a41 (diff)
downloadkernel-crypto-22adb358e816ce6aa0afb231ae9d826b0bddc8b0.tar.gz
kernel-crypto-22adb358e816ce6aa0afb231ae9d826b0bddc8b0.tar.xz
kernel-crypto-22adb358e816ce6aa0afb231ae9d826b0bddc8b0.zip
[SPARC64]: Eliminate NR_CPUS limitations.
Cheetah systems can have cpuids as large as 1023, although physical systems don't have that many cpus. Only three limitations existed in the kernel preventing arbitrary NR_CPUS values: 1) dcache dirty cpu state stored in page->flags on D-cache aliasing platforms. With some build time calculations and some build-time BUG checks on page->flags layout, this one was easily solved. 2) The cheetah XCALL delivery code could only handle a cpumask with up to 32 cpus set. Some simple looping logic clears that up too. 3) thread_info->cpu was a u8, easily changed to a u16. There are a few spots in the kernel that still put NR_CPUS sized arrays on the kernel stack, but that's not a sparc64 specific problem. Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'arch/sparc64/Kconfig')
-rw-r--r--arch/sparc64/Kconfig6
1 files changed, 3 insertions, 3 deletions
diff --git a/arch/sparc64/Kconfig b/arch/sparc64/Kconfig
index 831781cab27..bd00f89eed1 100644
--- a/arch/sparc64/Kconfig
+++ b/arch/sparc64/Kconfig
@@ -147,10 +147,10 @@ config SMP
If you don't know what to do here, say N.
config NR_CPUS
- int "Maximum number of CPUs (2-64)"
- range 2 64
+ int "Maximum number of CPUs (2-1024)"
+ range 2 1024
depends on SMP
- default "32"
+ default "64"
source "drivers/cpufreq/Kconfig"