| Message ID | 17087.1242609196@neuling.org (mailing list archive) |
|---|---|
| State | Accepted, archived |
| Commit | 2d8ae638bb86a3c7e8a7e610ec5ae545327d146a |
| Delegated to: | Benjamin Herrenschmidt |
| Headers | show |
On Mon, 2009-05-18 at 11:13 +1000, Michael Neuling wrote: > We can compile and boot with NR_CPUS=8192, so make this the max. 1024 > was an arbitrary decision anyway. Is 8192 still arbitrary? Or does something break above that? cheers
> > We can compile and boot with NR_CPUS=3D8192, so make this the max. 1024 > > was an arbitrary decision anyway. > > Is 8192 still arbitrary? Or does something break above that? Yeah, the compile breaks after that with 4K pages. In drivers/base/node.c we have: /* 2008/04/07: buf currently PAGE_SIZE, need 9 chars per 32 bits. */ BUILD_BUG_ON((NR_CPUS/32 * 9) > (PAGE_SIZE-1)); which causes: drivers/base/node.c: In function 'node_read_cpumap': drivers/base/node.c:31: error: size of array 'type name' is negative I can compile with 16384 CPUs with 64K pages, but it doesn't boot. sfr asked for size info for different builds, so I may as well repost them here: text data bss dec hex filename 9237767 3225768 4409996 16873531 101783b vmlinux.1024 9247355 4769472 7373708 21390535 14664c7 vmlinux.2048 9267239 7857032 13301132 30425403 1d0413b vmlinux.4096 9302623 14035832 25155980 48494435 2e3f763 vmlinux.8192 9373283 26389360 48865676 84628319 50b535f vmlinux.16384 config was pseries_defconfig but with 64K pages. Mikey
On Mon, 18 May 2009, Michael Neuling wrote: > > > We can compile and boot with NR_CPUS=3D8192, so make this the max. 1024 > > > was an arbitrary decision anyway. > > > > Is 8192 still arbitrary? Or does something break above that? > > Yeah, the compile breaks after that with 4K pages. > > In drivers/base/node.c we have: > /* 2008/04/07: buf currently PAGE_SIZE, need 9 chars per 32 bits. */ > BUILD_BUG_ON((NR_CPUS/32 * 9) > (PAGE_SIZE-1)); > which causes: > drivers/base/node.c: In function 'node_read_cpumap': > drivers/base/node.c:31: error: size of array 'type name' is negative > > I can compile with 16384 CPUs with 64K pages, but it doesn't boot. > > sfr asked for size info for different builds, so I may as well repost > them here: > > text data bss dec hex filename > 9237767 3225768 4409996 16873531 101783b vmlinux.1024 > 9247355 4769472 7373708 21390535 14664c7 vmlinux.2048 > 9267239 7857032 13301132 30425403 1d0413b vmlinux.4096 > 9302623 14035832 25155980 48494435 2e3f763 vmlinux.8192 > 9373283 26389360 48865676 84628319 50b535f vmlinux.16384 Will distros now start pushing NR_CPUS=8192-kernels on us? With kind regards, Geert Uytterhoeven Software Architect Techsoft Centre Technology and Software Centre Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone: +32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: Geert.Uytterhoeven@sonycom.com Internet: http://www.sony-europe.com/ A division of Sony Europe (Belgium) N.V. VAT BE 0413.825.160 · RPR Brussels Fortis · BIC GEBABEBB · IBAN BE41293037680010
In message <alpine.LRH.2.00.0905180857060.16754@vixen.sonytel.be> you wrote: > On Mon, 18 May 2009, Michael Neuling wrote: > > > > We can compile and boot with NR_CPUS=3D8192, so make this the max. 102 4 > > > > was an arbitrary decision anyway. > > > > > > Is 8192 still arbitrary? Or does something break above that? > > > > Yeah, the compile breaks after that with 4K pages. > > > > In drivers/base/node.c we have: > > /* 2008/04/07: buf currently PAGE_SIZE, need 9 chars per 32 bits. */ > > BUILD_BUG_ON((NR_CPUS/32 * 9) > (PAGE_SIZE-1)); > > which causes: > > drivers/base/node.c: In function 'node_read_cpumap': > > drivers/base/node.c:31: error: size of array 'type name' is negative > > > > I can compile with 16384 CPUs with 64K pages, but it doesn't boot. > > > > sfr asked for size info for different builds, so I may as well repost > > them here: > > > > text data bss dec hex filenam e > > 9237767 3225768 4409996 16873531 101783b vmlinux .1024 > > 9247355 4769472 7373708 21390535 14664c7 vmlinux .2048 > > 9267239 7857032 13301132 30425403 1d0413b vmlinux .4096 > > 9302623 14035832 25155980 48494435 2e3f763 vmlinux .8192 > > 9373283 26389360 48865676 84628319 50b535f vmlinux .16384 > > Will distros now start pushing NR_CPUS=8192-kernels on us? Yeah, that's a concern. Mikey
Index: linux-2.6-ozlabs/arch/powerpc/platforms/Kconfig.cputype =================================================================== --- linux-2.6-ozlabs.orig/arch/powerpc/platforms/Kconfig.cputype +++ linux-2.6-ozlabs/arch/powerpc/platforms/Kconfig.cputype @@ -262,8 +262,8 @@ config SMP If you don't know what to do here, say N. config NR_CPUS - int "Maximum number of CPUs (2-1024)" - range 2 1024 + int "Maximum number of CPUs (2-8192)" + range 2 8192 depends on SMP default "32" if PPC64 default "4"
We can compile and boot with NR_CPUS=8192, so make this the max. 1024 was an arbitrary decision anyway. Signed-off-by: Michael Neuling <mikey@neuling.org> -- No, I've not actually booted on a 8192 way machine, although if wishing made it so.... arch/powerpc/platforms/Kconfig.cputype | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)