[SPARC64]: Eliminate NR_CPUS limitations.
authorDavid S. Miller <davem@sunset.davemloft.net>
Sat, 26 May 2007 08:14:43 +0000 (01:14 -0700)
committerDavid S. Miller <davem@sunset.davemloft.net>
Tue, 29 May 2007 09:49:49 +0000 (02:49 -0700)
commit22adb358e816ce6aa0afb231ae9d826b0bddc8b0
tree6f9886bf5b4e5c916c72d8d5733211813873c5fc
parent5cbc30737398b49f62ae8603129ce43ac7db1a41
[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>
arch/sparc64/Kconfig
arch/sparc64/kernel/head.S
arch/sparc64/kernel/smp.c
arch/sparc64/mm/init.c
include/asm-sparc64/cpudata.h
include/asm-sparc64/thread_info.h