| Message ID | 20120331163321.GA15809@linux.vnet.ibm.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
Hi Paul, On Sat, Mar 31, 2012 at 18:33, Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: > Although there have been numerous complaints about the complexity of > parallel programming (especially over the past 5-10 years), the plain > truth is that the incremental complexity of parallel programming over > that of sequential programming is not as large as is commonly believed. > Despite that you might have heard, the mind-numbing complexity of modern > computer systems is not due so much to there being multiple CPUs, but > rather to there being any CPUs at all. In short, for the ultimate in > computer-system simplicity, the optimal choice is NR_CPUS=0. > > This commit therefore limits kernel builds to zero CPUs. This change > has the beneficial side effect of rendering all kernel bugs harmless. > Furthermore, this commit enables additional beneficial changes, for > example, the removal of those parts of the kernel that are not needed > when there are zero CPUs. > > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> > Reviewed-by: Thomas Gleixner <tglx@linutronix.de> > --- > > alpha/Kconfig | 11 ++++++----- > arm/Kconfig | 6 +++--- > blackfin/Kconfig | 3 ++- > hexagon/Kconfig | 9 +++++---- > ia64/Kconfig | 9 +++++---- > m32r/Kconfig | 10 ++++++---- > mips/Kconfig | 21 +++++++++++---------- > mn10300/Kconfig | 3 ++- > parisc/Kconfig | 6 +++--- > powerpc/platforms/Kconfig.cputype | 8 ++++---- > s390/Kconfig | 12 +++++++----- > sh/Kconfig | 11 ++++++----- > sparc/Kconfig | 8 ++++---- > tile/Kconfig | 9 +++++---- > x86/Kconfig | 16 +++++++++------- > 15 files changed, 78 insertions(+), 64 deletions(-) You forgot to fix half of the architectures, a.o. m68k? Gr{oetje,eeting}s, Geert (still at GMT+2) -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
On Sat, Mar 31, 2012 at 06:40:30PM +0200, Geert Uytterhoeven wrote: > Hi Paul, > > On Sat, Mar 31, 2012 at 18:33, Paul E. McKenney > <paulmck@linux.vnet.ibm.com> wrote: > > Although there have been numerous complaints about the complexity of > > parallel programming (especially over the past 5-10 years), the plain > > truth is that the incremental complexity of parallel programming over > > that of sequential programming is not as large as is commonly believed. > > Despite that you might have heard, the mind-numbing complexity of modern > > computer systems is not due so much to there being multiple CPUs, but > > rather to there being any CPUs at all. In short, for the ultimate in > > computer-system simplicity, the optimal choice is NR_CPUS=0. > > > > This commit therefore limits kernel builds to zero CPUs. This change > > has the beneficial side effect of rendering all kernel bugs harmless. > > Furthermore, this commit enables additional beneficial changes, for > > example, the removal of those parts of the kernel that are not needed > > when there are zero CPUs. > > > > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> > > Reviewed-by: Thomas Gleixner <tglx@linutronix.de> > > --- > > > > alpha/Kconfig | 11 ++++++----- > > arm/Kconfig | 6 +++--- > > blackfin/Kconfig | 3 ++- > > hexagon/Kconfig | 9 +++++---- > > ia64/Kconfig | 9 +++++---- > > m32r/Kconfig | 10 ++++++---- > > mips/Kconfig | 21 +++++++++++---------- > > mn10300/Kconfig | 3 ++- > > parisc/Kconfig | 6 +++--- > > powerpc/platforms/Kconfig.cputype | 8 ++++---- > > s390/Kconfig | 12 +++++++----- > > sh/Kconfig | 11 ++++++----- > > sparc/Kconfig | 8 ++++---- > > tile/Kconfig | 9 +++++---- > > x86/Kconfig | 16 +++++++++------- > > 15 files changed, 78 insertions(+), 64 deletions(-) > > You forgot to fix half of the architectures, a.o. m68k? I must confess that I fixed only the SMP-capable architectures. I of course would welcome additions for UP-only architectures. Thanx, Paul
Hi, I didn't actually try to compile the patch below; it didn't look like C code so I wasn't sure what compiler to run it through. I guess maybe its python? However, I'm very sure that the patches are completely correct, because I read them, and I also know that Paul is a trustworthy programmer. Thus, please add my ack Ack'ed by: Linas Vepstas <linasvepstas@gmail.com> On 31 March 2012 11:33, Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: > Although there have been numerous complaints about the complexity of > parallel programming (especially over the past 5-10 years), the plain > truth is that the incremental complexity of parallel programming over > that of sequential programming is not as large as is commonly believed. > Despite that you might have heard, the mind-numbing complexity of modern > computer systems is not due so much to there being multiple CPUs, but > rather to there being any CPUs at all. In short, for the ultimate in > computer-system simplicity, the optimal choice is NR_CPUS=0. > > This commit therefore limits kernel builds to zero CPUs. This change > has the beneficial side effect of rendering all kernel bugs harmless. > Furthermore, this commit enables additional beneficial changes, for > example, the removal of those parts of the kernel that are not needed > when there are zero CPUs. > > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> > Reviewed-by: Thomas Gleixner <tglx@linutronix.de> > --- > > alpha/Kconfig | 11 ++++++----- > arm/Kconfig | 6 +++--- > blackfin/Kconfig | 3 ++- > hexagon/Kconfig | 9 +++++---- > ia64/Kconfig | 9 +++++---- > m32r/Kconfig | 10 ++++++---- > mips/Kconfig | 21 +++++++++++---------- > mn10300/Kconfig | 3 ++- > parisc/Kconfig | 6 +++--- > powerpc/platforms/Kconfig.cputype | 8 ++++---- > s390/Kconfig | 12 +++++++----- > sh/Kconfig | 11 ++++++----- > sparc/Kconfig | 8 ++++---- > tile/Kconfig | 9 +++++---- > x86/Kconfig | 16 +++++++++------- > 15 files changed, 78 insertions(+), 64 deletions(-) > > diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig > index 56a4df9..1766b4a 100644 > --- a/arch/alpha/Kconfig > +++ b/arch/alpha/Kconfig > @@ -541,14 +541,15 @@ config HAVE_DEC_LOCK > default y > > config NR_CPUS > - int "Maximum number of CPUs (2-32)" > - range 2 32 > + int "Maximum number of CPUs (0-0)" > + range 0 0 > depends on SMP > - default "32" if ALPHA_GENERIC || ALPHA_MARVEL > - default "4" if !ALPHA_GENERIC && !ALPHA_MARVEL > + default "0" if ALPHA_GENERIC || ALPHA_MARVEL > + default "0" if !ALPHA_GENERIC && !ALPHA_MARVEL > help > MARVEL support can handle a maximum of 32 CPUs, all the others > - with working support have a maximum of 4 CPUs. > + with working support have a maximum of 4 CPUs. But why take > + chances? Just stick with zero CPUs. > > config ARCH_DISCONTIGMEM_ENABLE > bool "Discontiguous Memory Support (EXPERIMENTAL)" > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index a48aecc..1f07a3a 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -1551,10 +1551,10 @@ config PAGE_OFFSET > default 0xC0000000 > > config NR_CPUS > - int "Maximum number of CPUs (2-32)" > - range 2 32 > + int "Maximum number of CPUs (0-0)" > + range 0 0 > depends on SMP > - default "4" > + default "0" > > config HOTPLUG_CPU > bool "Support for hot-pluggable CPUs (EXPERIMENTAL)" > diff --git a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig > index abe5a9e..6a78549 100644 > --- a/arch/blackfin/Kconfig > +++ b/arch/blackfin/Kconfig > @@ -241,7 +241,8 @@ config SMP > config NR_CPUS > int > depends on SMP > - default 2 if BF561 > + range 0 0 > + default 0 if BF561 > > config HOTPLUG_CPU > bool "Support for hot-pluggable CPUs" > diff --git a/arch/hexagon/Kconfig b/arch/hexagon/Kconfig > index 9059e39..daab009 100644 > --- a/arch/hexagon/Kconfig > +++ b/arch/hexagon/Kconfig > @@ -158,13 +158,14 @@ config SMP > > config NR_CPUS > int "Maximum number of CPUs" if SMP > - range 2 6 if SMP > - default "1" if !SMP > - default "6" if SMP > + range 0 0 if SMP > + default "0" if !SMP > + default "0" if SMP > ---help--- > This allows you to specify the maximum number of CPUs which this > kernel will support. The maximum supported value is 6 and the > - minimum value which makes sense is 2. > + minimum value which makes sense is 2. But a limit of zero is > + so much safer! > > This is purely to save memory - each supported CPU adds > approximately eight kilobytes to the kernel image. > diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig > index bd72669..fea0e6d 100644 > --- a/arch/ia64/Kconfig > +++ b/arch/ia64/Kconfig > @@ -373,16 +373,17 @@ config SMP > If you don't know what to do here, say N. > > config NR_CPUS > - int "Maximum number of CPUs (2-4096)" > - range 2 4096 > + int "Maximum number of CPUs (0-0)" > + range 0 0 > depends on SMP > - default "4096" > + default "0" > help > You should set this to the number of CPUs in your system, but > keep in mind that a kernel compiled for, e.g., 2 CPUs will boot > but > only use 2 CPUs on a >2 CPU system. Setting this to a value > larger > than 64 will cause the use of a CPU mask array, causing a small > - performance hit. > + performance hit. And setting it larger than zero risks all > + manner of software bugs, so we just play it safe. > > config HOTPLUG_CPU > bool "Support for hot-pluggable CPUs (EXPERIMENTAL)" > diff --git a/arch/m32r/Kconfig b/arch/m32r/Kconfig > index ef80a65..68b9e88 100644 > --- a/arch/m32r/Kconfig > +++ b/arch/m32r/Kconfig > @@ -300,14 +300,16 @@ config CHIP_M32700_TS1 > default n > > config NR_CPUS > - int "Maximum number of CPUs (2-32)" > - range 2 32 > + int "Maximum number of CPUs (0-0)" > + range 0 0 > depends on SMP > - default "2" > + default "0" > help > This allows you to specify the maximum number of CPUs which this > kernel will support. The maximum supported value is 32 and the > - minimum value which makes sense is 2. > + minimum value which makes sense is 2. Zero may not make sense, > + but given that there is much in this world that does not make > + sense, zero it is! > > This is purely to save memory - each supported CPU adds > approximately eight kilobytes to the kernel image. > diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig > index 5ab6e89..3d7d06c 100644 > --- a/arch/mips/Kconfig > +++ b/arch/mips/Kconfig > @@ -2192,16 +2192,16 @@ config NR_CPUS_DEFAULT_64 > bool > > config NR_CPUS > - int "Maximum number of CPUs (2-64)" > - range 1 64 if NR_CPUS_DEFAULT_1 > + int "Maximum number of CPUs (0-0)" > + range 0 0 if NR_CPUS_DEFAULT_1 > depends on SMP > - default "1" if NR_CPUS_DEFAULT_1 > - default "2" if NR_CPUS_DEFAULT_2 > - default "4" if NR_CPUS_DEFAULT_4 > - default "8" if NR_CPUS_DEFAULT_8 > - default "16" if NR_CPUS_DEFAULT_16 > - default "32" if NR_CPUS_DEFAULT_32 > - default "64" if NR_CPUS_DEFAULT_64 > + default "0" if NR_CPUS_DEFAULT_1 > + default "0" if NR_CPUS_DEFAULT_2 > + default "0" if NR_CPUS_DEFAULT_4 > + default "0" if NR_CPUS_DEFAULT_8 > + default "0" if NR_CPUS_DEFAULT_16 > + default "0" if NR_CPUS_DEFAULT_32 > + default "0" if NR_CPUS_DEFAULT_64 > help > This allows you to specify the maximum number of CPUs which this > kernel will support. The maximum supported value is 32 for 32-bit > @@ -2212,7 +2212,8 @@ config NR_CPUS > This is purely to save memory - each supported CPU adds > approximately eight kilobytes to the kernel image. For best > performance should round up your number of processors to the next > - power of two. > + power of two. And just think how much more memory we will > + save by setting the limit to zero! > > source "kernel/time/Kconfig" > > diff --git a/arch/mn10300/Kconfig b/arch/mn10300/Kconfig > index 8f1c40d..85fc112 100644 > --- a/arch/mn10300/Kconfig > +++ b/arch/mn10300/Kconfig > @@ -201,7 +201,8 @@ config SMP > config NR_CPUS > int > depends on SMP > - default "2" > + range 0 0 > + default "0" > > source "kernel/Kconfig.preempt" > > diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig > index 242a1b7..358eaf8 100644 > --- a/arch/parisc/Kconfig > +++ b/arch/parisc/Kconfig > @@ -254,10 +254,10 @@ config HPUX > depends on !64BIT > > config NR_CPUS > - int "Maximum number of CPUs (2-32)" > - range 2 32 > + int "Maximum number of CPUs (0-0)" > + range 0 0 > depends on SMP > - default "32" > + default "0" > > endmenu > > diff --git a/arch/powerpc/platforms/Kconfig.cputype > b/arch/powerpc/platforms/Kconfig.cputype > index 425db18..5e607e0 100644 > --- a/arch/powerpc/platforms/Kconfig.cputype > +++ b/arch/powerpc/platforms/Kconfig.cputype > @@ -356,11 +356,11 @@ config SMP > If you don't know what to do here, say N. > > config NR_CPUS > - int "Maximum number of CPUs (2-8192)" > - range 2 8192 > + int "Maximum number of CPUs (0-0)" > + range 0 0 > depends on SMP > - default "32" if PPC64 > - default "4" > + default "0" if PPC64 > + default "0" > > config NOT_COHERENT_CACHE > bool > diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig > index d172758..f9bc067 100644 > --- a/arch/s390/Kconfig > +++ b/arch/s390/Kconfig > @@ -169,15 +169,17 @@ config SMP > Even if you don't know what to do here, say Y. > > config NR_CPUS > - int "Maximum number of CPUs (2-64)" > - range 2 64 > + int "Maximum number of CPUs (0-0)" > + range 0 0 > depends on SMP > - default "32" if !64BIT > - default "64" if 64BIT > + default "0" if !64BIT > + default "0" if 64BIT > help > This allows you to specify the maximum number of CPUs which this > kernel will support. The maximum supported value is 64 and the > - minimum value which makes sense is 2. > + minimum value which makes sense is 2. The minimal value that > + makes sense might well be 2, but we all know that the only > + -sane- value is zero! > > This is purely to save memory - each supported CPU adds > approximately sixteen kilobytes to the kernel image. > diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig > index 713fb58..5ddc7c0 100644 > --- a/arch/sh/Kconfig > +++ b/arch/sh/Kconfig > @@ -705,18 +705,19 @@ config SMP > If you don't know what to do here, say N. > > config NR_CPUS > - int "Maximum number of CPUs (2-32)" > - range 2 32 > + int "Maximum number of CPUs (0-0)" > + range 0 0 > depends on SMP > - default "4" if CPU_SUBTYPE_SHX3 > - default "2" > + default "0" if CPU_SUBTYPE_SHX3 > + default "0" > help > This allows you to specify the maximum number of CPUs which this > kernel will support. The maximum supported value is 32 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. > + approximately eight kilobytes to the kernel image. Debloating > + is the way, NR_CPUS to zero today!!! > > config HOTPLUG_CPU > bool "Support for hot-pluggable CPUs (EXPERIMENTAL)" > diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig > index ca5580e..0de9f0f 100644 > --- a/arch/sparc/Kconfig > +++ b/arch/sparc/Kconfig > @@ -177,10 +177,10 @@ config SMP > config NR_CPUS > int "Maximum number of CPUs" > depends on SMP > - range 2 32 if SPARC32 > - range 2 1024 if SPARC64 > - default 32 if SPARC32 > - default 64 if SPARC64 > + range 0 0 if SPARC32 > + range 0 0 if SPARC64 > + default 0 if SPARC32 > + default 0 if SPARC64 > > source kernel/Kconfig.hz > > diff --git a/arch/tile/Kconfig b/arch/tile/Kconfig > index 11270ca..a05112c 100644 > --- a/arch/tile/Kconfig > +++ b/arch/tile/Kconfig > @@ -126,14 +126,15 @@ source "init/Kconfig" > menu "Tilera-specific configuration" > > config NR_CPUS > - int "Maximum number of tiles (2-255)" > - range 2 255 > + int "Maximum number of tiles (0-0)" > + range 0 0 > depends on SMP > - default "64" > + default "0" > ---help--- > Building with 64 is the recommended value, but a slightly > smaller kernel memory footprint results from using a smaller > - value on chips with fewer tiles. > + value on chips with fewer tiles. To minimize both memory > + footprint and bugs, use zero and only zero. > > source "kernel/time/Kconfig" > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index 5bed94e..a6977f2 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -773,19 +773,21 @@ config MAXSMP > > config NR_CPUS > int "Maximum number of CPUs" if SMP && !MAXSMP > - range 2 8 if SMP && X86_32 && !X86_BIGSMP > - range 2 512 if SMP && !MAXSMP > - default "1" if !SMP > - default "4096" if MAXSMP > - default "32" if SMP && (X86_NUMAQ || X86_SUMMIT || X86_BIGSMP || > X86_ES7000) > - default "8" if SMP > + range 0 0 if SMP && X86_32 && !X86_BIGSMP > + range 0 0 if SMP && !MAXSMP > + default "0" if !SMP > + default "0" if MAXSMP > + default "0" if SMP && (X86_NUMAQ || X86_SUMMIT || X86_BIGSMP || > X86_ES7000) > + default "0" if SMP > ---help--- > This allows you to specify the maximum number of CPUs which this > 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. > + approximately eight kilobytes to the kernel image. But > + the first supported CPU brings a lot of bugs with it, so > + for ultimate reliability, set the number of CPUs to zero. > > config SCHED_SMT > bool "SMT (Hyperthreading) scheduler support" > > -- > To unsubscribe from this list: send the line "unsubscribe linux-hexagon" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
On Sat, Mar 31, 2012 at 02:57:46PM -0500, Linas Vepstas wrote: > Hi, > > I didn't actually try to compile the patch below; it didn't look like C > code so I wasn't sure what compiler to run it through. I guess maybe its > python? However, I'm very sure that the patches are completely correct, > because I read them, and I also know that Paul is a trustworthy programmer. > Thus, please add my ack > > Ack'ed by: Linas Vepstas <linasvepstas@gmail.com> It is Linux-kernel Kconfig language, which processed during kernel builds. I have added your Acked-by. ;-) Thanx, Paul > On 31 March 2012 11:33, Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: > > > Although there have been numerous complaints about the complexity of > > parallel programming (especially over the past 5-10 years), the plain > > truth is that the incremental complexity of parallel programming over > > that of sequential programming is not as large as is commonly believed. > > Despite that you might have heard, the mind-numbing complexity of modern > > computer systems is not due so much to there being multiple CPUs, but > > rather to there being any CPUs at all. In short, for the ultimate in > > computer-system simplicity, the optimal choice is NR_CPUS=0. > > > > This commit therefore limits kernel builds to zero CPUs. This change > > has the beneficial side effect of rendering all kernel bugs harmless. > > Furthermore, this commit enables additional beneficial changes, for > > example, the removal of those parts of the kernel that are not needed > > when there are zero CPUs. > > > > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> > > Reviewed-by: Thomas Gleixner <tglx@linutronix.de> > > --- > > > > alpha/Kconfig | 11 ++++++----- > > arm/Kconfig | 6 +++--- > > blackfin/Kconfig | 3 ++- > > hexagon/Kconfig | 9 +++++---- > > ia64/Kconfig | 9 +++++---- > > m32r/Kconfig | 10 ++++++---- > > mips/Kconfig | 21 +++++++++++---------- > > mn10300/Kconfig | 3 ++- > > parisc/Kconfig | 6 +++--- > > powerpc/platforms/Kconfig.cputype | 8 ++++---- > > s390/Kconfig | 12 +++++++----- > > sh/Kconfig | 11 ++++++----- > > sparc/Kconfig | 8 ++++---- > > tile/Kconfig | 9 +++++---- > > x86/Kconfig | 16 +++++++++------- > > 15 files changed, 78 insertions(+), 64 deletions(-) > > > > diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig > > index 56a4df9..1766b4a 100644 > > --- a/arch/alpha/Kconfig > > +++ b/arch/alpha/Kconfig > > @@ -541,14 +541,15 @@ config HAVE_DEC_LOCK > > default y > > > > config NR_CPUS > > - int "Maximum number of CPUs (2-32)" > > - range 2 32 > > + int "Maximum number of CPUs (0-0)" > > + range 0 0 > > depends on SMP > > - default "32" if ALPHA_GENERIC || ALPHA_MARVEL > > - default "4" if !ALPHA_GENERIC && !ALPHA_MARVEL > > + default "0" if ALPHA_GENERIC || ALPHA_MARVEL > > + default "0" if !ALPHA_GENERIC && !ALPHA_MARVEL > > help > > MARVEL support can handle a maximum of 32 CPUs, all the others > > - with working support have a maximum of 4 CPUs. > > + with working support have a maximum of 4 CPUs. But why take > > + chances? Just stick with zero CPUs. > > > > config ARCH_DISCONTIGMEM_ENABLE > > bool "Discontiguous Memory Support (EXPERIMENTAL)" > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > > index a48aecc..1f07a3a 100644 > > --- a/arch/arm/Kconfig > > +++ b/arch/arm/Kconfig > > @@ -1551,10 +1551,10 @@ config PAGE_OFFSET > > default 0xC0000000 > > > > config NR_CPUS > > - int "Maximum number of CPUs (2-32)" > > - range 2 32 > > + int "Maximum number of CPUs (0-0)" > > + range 0 0 > > depends on SMP > > - default "4" > > + default "0" > > > > config HOTPLUG_CPU > > bool "Support for hot-pluggable CPUs (EXPERIMENTAL)" > > diff --git a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig > > index abe5a9e..6a78549 100644 > > --- a/arch/blackfin/Kconfig > > +++ b/arch/blackfin/Kconfig > > @@ -241,7 +241,8 @@ config SMP > > config NR_CPUS > > int > > depends on SMP > > - default 2 if BF561 > > + range 0 0 > > + default 0 if BF561 > > > > config HOTPLUG_CPU > > bool "Support for hot-pluggable CPUs" > > diff --git a/arch/hexagon/Kconfig b/arch/hexagon/Kconfig > > index 9059e39..daab009 100644 > > --- a/arch/hexagon/Kconfig > > +++ b/arch/hexagon/Kconfig > > @@ -158,13 +158,14 @@ config SMP > > > > config NR_CPUS > > int "Maximum number of CPUs" if SMP > > - range 2 6 if SMP > > - default "1" if !SMP > > - default "6" if SMP > > + range 0 0 if SMP > > + default "0" if !SMP > > + default "0" if SMP > > ---help--- > > This allows you to specify the maximum number of CPUs which this > > kernel will support. The maximum supported value is 6 and the > > - minimum value which makes sense is 2. > > + minimum value which makes sense is 2. But a limit of zero is > > + so much safer! > > > > This is purely to save memory - each supported CPU adds > > approximately eight kilobytes to the kernel image. > > diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig > > index bd72669..fea0e6d 100644 > > --- a/arch/ia64/Kconfig > > +++ b/arch/ia64/Kconfig > > @@ -373,16 +373,17 @@ config SMP > > If you don't know what to do here, say N. > > > > config NR_CPUS > > - int "Maximum number of CPUs (2-4096)" > > - range 2 4096 > > + int "Maximum number of CPUs (0-0)" > > + range 0 0 > > depends on SMP > > - default "4096" > > + default "0" > > help > > You should set this to the number of CPUs in your system, but > > keep in mind that a kernel compiled for, e.g., 2 CPUs will boot > > but > > only use 2 CPUs on a >2 CPU system. Setting this to a value > > larger > > than 64 will cause the use of a CPU mask array, causing a small > > - performance hit. > > + performance hit. And setting it larger than zero risks all > > + manner of software bugs, so we just play it safe. > > > > config HOTPLUG_CPU > > bool "Support for hot-pluggable CPUs (EXPERIMENTAL)" > > diff --git a/arch/m32r/Kconfig b/arch/m32r/Kconfig > > index ef80a65..68b9e88 100644 > > --- a/arch/m32r/Kconfig > > +++ b/arch/m32r/Kconfig > > @@ -300,14 +300,16 @@ config CHIP_M32700_TS1 > > default n > > > > config NR_CPUS > > - int "Maximum number of CPUs (2-32)" > > - range 2 32 > > + int "Maximum number of CPUs (0-0)" > > + range 0 0 > > depends on SMP > > - default "2" > > + default "0" > > help > > This allows you to specify the maximum number of CPUs which this > > kernel will support. The maximum supported value is 32 and the > > - minimum value which makes sense is 2. > > + minimum value which makes sense is 2. Zero may not make sense, > > + but given that there is much in this world that does not make > > + sense, zero it is! > > > > This is purely to save memory - each supported CPU adds > > approximately eight kilobytes to the kernel image. > > diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig > > index 5ab6e89..3d7d06c 100644 > > --- a/arch/mips/Kconfig > > +++ b/arch/mips/Kconfig > > @@ -2192,16 +2192,16 @@ config NR_CPUS_DEFAULT_64 > > bool > > > > config NR_CPUS > > - int "Maximum number of CPUs (2-64)" > > - range 1 64 if NR_CPUS_DEFAULT_1 > > + int "Maximum number of CPUs (0-0)" > > + range 0 0 if NR_CPUS_DEFAULT_1 > > depends on SMP > > - default "1" if NR_CPUS_DEFAULT_1 > > - default "2" if NR_CPUS_DEFAULT_2 > > - default "4" if NR_CPUS_DEFAULT_4 > > - default "8" if NR_CPUS_DEFAULT_8 > > - default "16" if NR_CPUS_DEFAULT_16 > > - default "32" if NR_CPUS_DEFAULT_32 > > - default "64" if NR_CPUS_DEFAULT_64 > > + default "0" if NR_CPUS_DEFAULT_1 > > + default "0" if NR_CPUS_DEFAULT_2 > > + default "0" if NR_CPUS_DEFAULT_4 > > + default "0" if NR_CPUS_DEFAULT_8 > > + default "0" if NR_CPUS_DEFAULT_16 > > + default "0" if NR_CPUS_DEFAULT_32 > > + default "0" if NR_CPUS_DEFAULT_64 > > help > > This allows you to specify the maximum number of CPUs which this > > kernel will support. The maximum supported value is 32 for 32-bit > > @@ -2212,7 +2212,8 @@ config NR_CPUS > > This is purely to save memory - each supported CPU adds > > approximately eight kilobytes to the kernel image. For best > > performance should round up your number of processors to the next > > - power of two. > > + power of two. And just think how much more memory we will > > + save by setting the limit to zero! > > > > source "kernel/time/Kconfig" > > > > diff --git a/arch/mn10300/Kconfig b/arch/mn10300/Kconfig > > index 8f1c40d..85fc112 100644 > > --- a/arch/mn10300/Kconfig > > +++ b/arch/mn10300/Kconfig > > @@ -201,7 +201,8 @@ config SMP > > config NR_CPUS > > int > > depends on SMP > > - default "2" > > + range 0 0 > > + default "0" > > > > source "kernel/Kconfig.preempt" > > > > diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig > > index 242a1b7..358eaf8 100644 > > --- a/arch/parisc/Kconfig > > +++ b/arch/parisc/Kconfig > > @@ -254,10 +254,10 @@ config HPUX > > depends on !64BIT > > > > config NR_CPUS > > - int "Maximum number of CPUs (2-32)" > > - range 2 32 > > + int "Maximum number of CPUs (0-0)" > > + range 0 0 > > depends on SMP > > - default "32" > > + default "0" > > > > endmenu > > > > diff --git a/arch/powerpc/platforms/Kconfig.cputype > > b/arch/powerpc/platforms/Kconfig.cputype > > index 425db18..5e607e0 100644 > > --- a/arch/powerpc/platforms/Kconfig.cputype > > +++ b/arch/powerpc/platforms/Kconfig.cputype > > @@ -356,11 +356,11 @@ config SMP > > If you don't know what to do here, say N. > > > > config NR_CPUS > > - int "Maximum number of CPUs (2-8192)" > > - range 2 8192 > > + int "Maximum number of CPUs (0-0)" > > + range 0 0 > > depends on SMP > > - default "32" if PPC64 > > - default "4" > > + default "0" if PPC64 > > + default "0" > > > > config NOT_COHERENT_CACHE > > bool > > diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig > > index d172758..f9bc067 100644 > > --- a/arch/s390/Kconfig > > +++ b/arch/s390/Kconfig > > @@ -169,15 +169,17 @@ config SMP > > Even if you don't know what to do here, say Y. > > > > config NR_CPUS > > - int "Maximum number of CPUs (2-64)" > > - range 2 64 > > + int "Maximum number of CPUs (0-0)" > > + range 0 0 > > depends on SMP > > - default "32" if !64BIT > > - default "64" if 64BIT > > + default "0" if !64BIT > > + default "0" if 64BIT > > help > > This allows you to specify the maximum number of CPUs which this > > kernel will support. The maximum supported value is 64 and the > > - minimum value which makes sense is 2. > > + minimum value which makes sense is 2. The minimal value that > > + makes sense might well be 2, but we all know that the only > > + -sane- value is zero! > > > > This is purely to save memory - each supported CPU adds > > approximately sixteen kilobytes to the kernel image. > > diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig > > index 713fb58..5ddc7c0 100644 > > --- a/arch/sh/Kconfig > > +++ b/arch/sh/Kconfig > > @@ -705,18 +705,19 @@ config SMP > > If you don't know what to do here, say N. > > > > config NR_CPUS > > - int "Maximum number of CPUs (2-32)" > > - range 2 32 > > + int "Maximum number of CPUs (0-0)" > > + range 0 0 > > depends on SMP > > - default "4" if CPU_SUBTYPE_SHX3 > > - default "2" > > + default "0" if CPU_SUBTYPE_SHX3 > > + default "0" > > help > > This allows you to specify the maximum number of CPUs which this > > kernel will support. The maximum supported value is 32 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. > > + approximately eight kilobytes to the kernel image. Debloating > > + is the way, NR_CPUS to zero today!!! > > > > config HOTPLUG_CPU > > bool "Support for hot-pluggable CPUs (EXPERIMENTAL)" > > diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig > > index ca5580e..0de9f0f 100644 > > --- a/arch/sparc/Kconfig > > +++ b/arch/sparc/Kconfig > > @@ -177,10 +177,10 @@ config SMP > > config NR_CPUS > > int "Maximum number of CPUs" > > depends on SMP > > - range 2 32 if SPARC32 > > - range 2 1024 if SPARC64 > > - default 32 if SPARC32 > > - default 64 if SPARC64 > > + range 0 0 if SPARC32 > > + range 0 0 if SPARC64 > > + default 0 if SPARC32 > > + default 0 if SPARC64 > > > > source kernel/Kconfig.hz > > > > diff --git a/arch/tile/Kconfig b/arch/tile/Kconfig > > index 11270ca..a05112c 100644 > > --- a/arch/tile/Kconfig > > +++ b/arch/tile/Kconfig > > @@ -126,14 +126,15 @@ source "init/Kconfig" > > menu "Tilera-specific configuration" > > > > config NR_CPUS > > - int "Maximum number of tiles (2-255)" > > - range 2 255 > > + int "Maximum number of tiles (0-0)" > > + range 0 0 > > depends on SMP > > - default "64" > > + default "0" > > ---help--- > > Building with 64 is the recommended value, but a slightly > > smaller kernel memory footprint results from using a smaller > > - value on chips with fewer tiles. > > + value on chips with fewer tiles. To minimize both memory > > + footprint and bugs, use zero and only zero. > > > > source "kernel/time/Kconfig" > > > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > > index 5bed94e..a6977f2 100644 > > --- a/arch/x86/Kconfig > > +++ b/arch/x86/Kconfig > > @@ -773,19 +773,21 @@ config MAXSMP > > > > config NR_CPUS > > int "Maximum number of CPUs" if SMP && !MAXSMP > > - range 2 8 if SMP && X86_32 && !X86_BIGSMP > > - range 2 512 if SMP && !MAXSMP > > - default "1" if !SMP > > - default "4096" if MAXSMP > > - default "32" if SMP && (X86_NUMAQ || X86_SUMMIT || X86_BIGSMP || > > X86_ES7000) > > - default "8" if SMP > > + range 0 0 if SMP && X86_32 && !X86_BIGSMP > > + range 0 0 if SMP && !MAXSMP > > + default "0" if !SMP > > + default "0" if MAXSMP > > + default "0" if SMP && (X86_NUMAQ || X86_SUMMIT || X86_BIGSMP || > > X86_ES7000) > > + default "0" if SMP > > ---help--- > > This allows you to specify the maximum number of CPUs which this > > 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. > > + approximately eight kilobytes to the kernel image. But > > + the first supported CPU brings a lot of bugs with it, so > > + for ultimate reliability, set the number of CPUs to zero. > > > > config SCHED_SMT > > bool "SMT (Hyperthreading) scheduler support" > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-hexagon" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > >
Hi, I didn't actually try to compile the patch below; it didn't look like C code so I wasn't sure what compiler to run it through. I guess maybe its python? However, I'm very sure that the patches are completely correct, because I read them, and I also know Paul. And I've heard of Thomas Gleixner. Thus, please add my ack -- Ack'ed by: Linas Vepstas <linasvepstas@gmail.com> On Sun, Apr 01, 2012 at 12:33:21AM +0800, Paul E. McKenney was heard to remark: > Although there have been numerous complaints about the complexity of > parallel programming (especially over the past 5-10 years), the plain > truth is that the incremental complexity of parallel programming over > that of sequential programming is not as large as is commonly believed. > Despite that you might have heard, the mind-numbing complexity of modern > computer systems is not due so much to there being multiple CPUs, but > rather to there being any CPUs at all. In short, for the ultimate in > computer-system simplicity, the optimal choice is NR_CPUS=0. > > This commit therefore limits kernel builds to zero CPUs. This change > has the beneficial side effect of rendering all kernel bugs harmless. > Furthermore, this commit enables additional beneficial changes, for > example, the removal of those parts of the kernel that are not needed > when there are zero CPUs. > > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> > Reviewed-by: Thomas Gleixner <tglx@linutronix.de> > --- > > alpha/Kconfig | 11 ++++++----- > arm/Kconfig | 6 +++--- > blackfin/Kconfig | 3 ++- > hexagon/Kconfig | 9 +++++---- > ia64/Kconfig | 9 +++++---- > m32r/Kconfig | 10 ++++++---- > mips/Kconfig | 21 +++++++++++---------- > mn10300/Kconfig | 3 ++- > parisc/Kconfig | 6 +++--- > powerpc/platforms/Kconfig.cputype | 8 ++++---- > s390/Kconfig | 12 +++++++----- > sh/Kconfig | 11 ++++++----- > sparc/Kconfig | 8 ++++---- > tile/Kconfig | 9 +++++---- > x86/Kconfig | 16 +++++++++------- > 15 files changed, 78 insertions(+), 64 deletions(-) > > diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig > index 56a4df9..1766b4a 100644 > --- a/arch/alpha/Kconfig > +++ b/arch/alpha/Kconfig > @@ -541,14 +541,15 @@ config HAVE_DEC_LOCK > default y > > config NR_CPUS > - int "Maximum number of CPUs (2-32)" > - range 2 32 > + int "Maximum number of CPUs (0-0)" > + range 0 0 > depends on SMP > - default "32" if ALPHA_GENERIC || ALPHA_MARVEL > - default "4" if !ALPHA_GENERIC && !ALPHA_MARVEL > + default "0" if ALPHA_GENERIC || ALPHA_MARVEL > + default "0" if !ALPHA_GENERIC && !ALPHA_MARVEL > help > MARVEL support can handle a maximum of 32 CPUs, all the others > - with working support have a maximum of 4 CPUs. > + with working support have a maximum of 4 CPUs. But why take > + chances? Just stick with zero CPUs. > > config ARCH_DISCONTIGMEM_ENABLE > bool "Discontiguous Memory Support (EXPERIMENTAL)" > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index a48aecc..1f07a3a 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -1551,10 +1551,10 @@ config PAGE_OFFSET > default 0xC0000000 > > config NR_CPUS > - int "Maximum number of CPUs (2-32)" > - range 2 32 > + int "Maximum number of CPUs (0-0)" > + range 0 0 > depends on SMP > - default "4" > + default "0" > > config HOTPLUG_CPU > bool "Support for hot-pluggable CPUs (EXPERIMENTAL)" > diff --git a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig > index abe5a9e..6a78549 100644 > --- a/arch/blackfin/Kconfig > +++ b/arch/blackfin/Kconfig > @@ -241,7 +241,8 @@ config SMP > config NR_CPUS > int > depends on SMP > - default 2 if BF561 > + range 0 0 > + default 0 if BF561 > > config HOTPLUG_CPU > bool "Support for hot-pluggable CPUs" > diff --git a/arch/hexagon/Kconfig b/arch/hexagon/Kconfig > index 9059e39..daab009 100644 > --- a/arch/hexagon/Kconfig > +++ b/arch/hexagon/Kconfig > @@ -158,13 +158,14 @@ config SMP > > config NR_CPUS > int "Maximum number of CPUs" if SMP > - range 2 6 if SMP > - default "1" if !SMP > - default "6" if SMP > + range 0 0 if SMP > + default "0" if !SMP > + default "0" if SMP > ---help--- > This allows you to specify the maximum number of CPUs which this > kernel will support. The maximum supported value is 6 and the > - minimum value which makes sense is 2. > + minimum value which makes sense is 2. But a limit of zero is > + so much safer! > > This is purely to save memory - each supported CPU adds > approximately eight kilobytes to the kernel image. > diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig > index bd72669..fea0e6d 100644 > --- a/arch/ia64/Kconfig > +++ b/arch/ia64/Kconfig > @@ -373,16 +373,17 @@ config SMP > If you don't know what to do here, say N. > > config NR_CPUS > - int "Maximum number of CPUs (2-4096)" > - range 2 4096 > + int "Maximum number of CPUs (0-0)" > + range 0 0 > depends on SMP > - default "4096" > + default "0" > help > You should set this to the number of CPUs in your system, but > keep in mind that a kernel compiled for, e.g., 2 CPUs will boot but > only use 2 CPUs on a >2 CPU system. Setting this to a value larger > than 64 will cause the use of a CPU mask array, causing a small > - performance hit. > + performance hit. And setting it larger than zero risks all > + manner of software bugs, so we just play it safe. > > config HOTPLUG_CPU > bool "Support for hot-pluggable CPUs (EXPERIMENTAL)" > diff --git a/arch/m32r/Kconfig b/arch/m32r/Kconfig > index ef80a65..68b9e88 100644 > --- a/arch/m32r/Kconfig > +++ b/arch/m32r/Kconfig > @@ -300,14 +300,16 @@ config CHIP_M32700_TS1 > default n > > config NR_CPUS > - int "Maximum number of CPUs (2-32)" > - range 2 32 > + int "Maximum number of CPUs (0-0)" > + range 0 0 > depends on SMP > - default "2" > + default "0" > help > This allows you to specify the maximum number of CPUs which this > kernel will support. The maximum supported value is 32 and the > - minimum value which makes sense is 2. > + minimum value which makes sense is 2. Zero may not make sense, > + but given that there is much in this world that does not make > + sense, zero it is! > > This is purely to save memory - each supported CPU adds > approximately eight kilobytes to the kernel image. > diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig > index 5ab6e89..3d7d06c 100644 > --- a/arch/mips/Kconfig > +++ b/arch/mips/Kconfig > @@ -2192,16 +2192,16 @@ config NR_CPUS_DEFAULT_64 > bool > > config NR_CPUS > - int "Maximum number of CPUs (2-64)" > - range 1 64 if NR_CPUS_DEFAULT_1 > + int "Maximum number of CPUs (0-0)" > + range 0 0 if NR_CPUS_DEFAULT_1 > depends on SMP > - default "1" if NR_CPUS_DEFAULT_1 > - default "2" if NR_CPUS_DEFAULT_2 > - default "4" if NR_CPUS_DEFAULT_4 > - default "8" if NR_CPUS_DEFAULT_8 > - default "16" if NR_CPUS_DEFAULT_16 > - default "32" if NR_CPUS_DEFAULT_32 > - default "64" if NR_CPUS_DEFAULT_64 > + default "0" if NR_CPUS_DEFAULT_1 > + default "0" if NR_CPUS_DEFAULT_2 > + default "0" if NR_CPUS_DEFAULT_4 > + default "0" if NR_CPUS_DEFAULT_8 > + default "0" if NR_CPUS_DEFAULT_16 > + default "0" if NR_CPUS_DEFAULT_32 > + default "0" if NR_CPUS_DEFAULT_64 > help > This allows you to specify the maximum number of CPUs which this > kernel will support. The maximum supported value is 32 for 32-bit > @@ -2212,7 +2212,8 @@ config NR_CPUS > This is purely to save memory - each supported CPU adds > approximately eight kilobytes to the kernel image. For best > performance should round up your number of processors to the next > - power of two. > + power of two. And just think how much more memory we will > + save by setting the limit to zero! > > source "kernel/time/Kconfig" > > diff --git a/arch/mn10300/Kconfig b/arch/mn10300/Kconfig > index 8f1c40d..85fc112 100644 > --- a/arch/mn10300/Kconfig > +++ b/arch/mn10300/Kconfig > @@ -201,7 +201,8 @@ config SMP > config NR_CPUS > int > depends on SMP > - default "2" > + range 0 0 > + default "0" > > source "kernel/Kconfig.preempt" > > diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig > index 242a1b7..358eaf8 100644 > --- a/arch/parisc/Kconfig > +++ b/arch/parisc/Kconfig > @@ -254,10 +254,10 @@ config HPUX > depends on !64BIT > > config NR_CPUS > - int "Maximum number of CPUs (2-32)" > - range 2 32 > + int "Maximum number of CPUs (0-0)" > + range 0 0 > depends on SMP > - default "32" > + default "0" > > endmenu > > diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype > index 425db18..5e607e0 100644 > --- a/arch/powerpc/platforms/Kconfig.cputype > +++ b/arch/powerpc/platforms/Kconfig.cputype > @@ -356,11 +356,11 @@ config SMP > If you don't know what to do here, say N. > > config NR_CPUS > - int "Maximum number of CPUs (2-8192)" > - range 2 8192 > + int "Maximum number of CPUs (0-0)" > + range 0 0 > depends on SMP > - default "32" if PPC64 > - default "4" > + default "0" if PPC64 > + default "0" > > config NOT_COHERENT_CACHE > bool > diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig > index d172758..f9bc067 100644 > --- a/arch/s390/Kconfig > +++ b/arch/s390/Kconfig > @@ -169,15 +169,17 @@ config SMP > Even if you don't know what to do here, say Y. > > config NR_CPUS > - int "Maximum number of CPUs (2-64)" > - range 2 64 > + int "Maximum number of CPUs (0-0)" > + range 0 0 > depends on SMP > - default "32" if !64BIT > - default "64" if 64BIT > + default "0" if !64BIT > + default "0" if 64BIT > help > This allows you to specify the maximum number of CPUs which this > kernel will support. The maximum supported value is 64 and the > - minimum value which makes sense is 2. > + minimum value which makes sense is 2. The minimal value that > + makes sense might well be 2, but we all know that the only > + -sane- value is zero! > > This is purely to save memory - each supported CPU adds > approximately sixteen kilobytes to the kernel image. > diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig > index 713fb58..5ddc7c0 100644 > --- a/arch/sh/Kconfig > +++ b/arch/sh/Kconfig > @@ -705,18 +705,19 @@ config SMP > If you don't know what to do here, say N. > > config NR_CPUS > - int "Maximum number of CPUs (2-32)" > - range 2 32 > + int "Maximum number of CPUs (0-0)" > + range 0 0 > depends on SMP > - default "4" if CPU_SUBTYPE_SHX3 > - default "2" > + default "0" if CPU_SUBTYPE_SHX3 > + default "0" > help > This allows you to specify the maximum number of CPUs which this > kernel will support. The maximum supported value is 32 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. > + approximately eight kilobytes to the kernel image. Debloating > + is the way, NR_CPUS to zero today!!! > > config HOTPLUG_CPU > bool "Support for hot-pluggable CPUs (EXPERIMENTAL)" > diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig > index ca5580e..0de9f0f 100644 > --- a/arch/sparc/Kconfig > +++ b/arch/sparc/Kconfig > @@ -177,10 +177,10 @@ config SMP > config NR_CPUS > int "Maximum number of CPUs" > depends on SMP > - range 2 32 if SPARC32 > - range 2 1024 if SPARC64 > - default 32 if SPARC32 > - default 64 if SPARC64 > + range 0 0 if SPARC32 > + range 0 0 if SPARC64 > + default 0 if SPARC32 > + default 0 if SPARC64 > > source kernel/Kconfig.hz > > diff --git a/arch/tile/Kconfig b/arch/tile/Kconfig > index 11270ca..a05112c 100644 > --- a/arch/tile/Kconfig > +++ b/arch/tile/Kconfig > @@ -126,14 +126,15 @@ source "init/Kconfig" > menu "Tilera-specific configuration" > > config NR_CPUS > - int "Maximum number of tiles (2-255)" > - range 2 255 > + int "Maximum number of tiles (0-0)" > + range 0 0 > depends on SMP > - default "64" > + default "0" > ---help--- > Building with 64 is the recommended value, but a slightly > smaller kernel memory footprint results from using a smaller > - value on chips with fewer tiles. > + value on chips with fewer tiles. To minimize both memory > + footprint and bugs, use zero and only zero. > > source "kernel/time/Kconfig" > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index 5bed94e..a6977f2 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -773,19 +773,21 @@ config MAXSMP > > config NR_CPUS > int "Maximum number of CPUs" if SMP && !MAXSMP > - range 2 8 if SMP && X86_32 && !X86_BIGSMP > - range 2 512 if SMP && !MAXSMP > - default "1" if !SMP > - default "4096" if MAXSMP > - default "32" if SMP && (X86_NUMAQ || X86_SUMMIT || X86_BIGSMP || X86_ES7000) > - default "8" if SMP > + range 0 0 if SMP && X86_32 && !X86_BIGSMP > + range 0 0 if SMP && !MAXSMP > + default "0" if !SMP > + default "0" if MAXSMP > + default "0" if SMP && (X86_NUMAQ || X86_SUMMIT || X86_BIGSMP || X86_ES7000) > + default "0" if SMP > ---help--- > This allows you to specify the maximum number of CPUs which this > 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. > + approximately eight kilobytes to the kernel image. But > + the first supported CPU brings a lot of bugs with it, so > + for ultimate reliability, set the number of CPUs to zero. > > config SCHED_SMT > bool "SMT (Hyperthreading) scheduler support" > > -- > To unsubscribe from this list: send the line "unsubscribe linux-hexagon" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
On 03/31/2012 01:15 PM, Linas Vepstas wrote: > > Hi, > > I didn't actually try to compile the patch below; it didn't look like > C code so I wasn't sure what compiler to run it through. I guess maybe > its python? However, I'm very sure that the patches are completely > correct, because I read them, and I also know Paul. And I've heard of > Thomas Gleixner. x86_64 defconfig has many build errors and warnings. :( back to my abacus.
On Sat, Mar 31, 2012 at 01:25:02PM -0700, Randy Dunlap wrote: > On 03/31/2012 01:15 PM, Linas Vepstas wrote: > > > > > Hi, > > > > I didn't actually try to compile the patch below; it didn't look like > > C code so I wasn't sure what compiler to run it through. I guess maybe > > its python? However, I'm very sure that the patches are completely > > correct, because I read them, and I also know Paul. And I've heard of > > Thomas Gleixner. > > > x86_64 defconfig has many build errors and warnings. :( I suggest removing the code containing the errors and warnings. I bet that the offending code is not needed when running with zero CPUs. > back to my abacus. ;-) Thanx, Paul
On Sun, 2012-04-01 at 00:33 +0800, Paul E. McKenney wrote: > Although there have been numerous complaints about the complexity of > parallel programming (especially over the past 5-10 years), the plain > truth is that the incremental complexity of parallel programming over > that of sequential programming is not as large as is commonly believed. > Despite that you might have heard, the mind-numbing complexity of modern > computer systems is not due so much to there being multiple CPUs, but > rather to there being any CPUs at all. In short, for the ultimate in > computer-system simplicity, the optimal choice is NR_CPUS=0. > > This commit therefore limits kernel builds to zero CPUs. This change > has the beneficial side effect of rendering all kernel bugs harmless. > Furthermore, this commit enables additional beneficial changes, for > example, the removal of those parts of the kernel that are not needed > when there are zero CPUs. > > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> > Reviewed-by: Thomas Gleixner <tglx@linutronix.de> > --- Hmm... I believe you could go one step forward and allow negative values as well. Antimatter was proven to exist after all. Hint : nr_cpu_ids is an "int", not an "unsigned int" Bonus: Existing bugs become "must have" features. Of course there is no hurry and this can wait 365 days.
On Sat, Mar 31, 2012 at 11:00:08PM +0200, Eric Dumazet wrote: > On Sun, 2012-04-01 at 00:33 +0800, Paul E. McKenney wrote: > > Although there have been numerous complaints about the complexity of > > parallel programming (especially over the past 5-10 years), the plain > > truth is that the incremental complexity of parallel programming over > > that of sequential programming is not as large as is commonly believed. > > Despite that you might have heard, the mind-numbing complexity of modern > > computer systems is not due so much to there being multiple CPUs, but > > rather to there being any CPUs at all. In short, for the ultimate in > > computer-system simplicity, the optimal choice is NR_CPUS=0. > > > > This commit therefore limits kernel builds to zero CPUs. This change > > has the beneficial side effect of rendering all kernel bugs harmless. > > Furthermore, this commit enables additional beneficial changes, for > > example, the removal of those parts of the kernel that are not needed > > when there are zero CPUs. > > > > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> > > Reviewed-by: Thomas Gleixner <tglx@linutronix.de> > > --- > > Hmm... I believe you could go one step forward and allow negative values > as well. Antimatter was proven to exist after all. > > Hint : nr_cpu_ids is an "int", not an "unsigned int" > > Bonus: Existing bugs become "must have" features. ;-) ;-) ;-) > Of course there is no hurry and this can wait 365 days. James Bottomley suggested imaginary numbers of CPUs some time back, and I suppose there is no reason you cannot have fractional numbers of CPUs, and perhaps irrational numbers as well. Of course, these last two would require use of floating-point arithmetic (or something similar) in the kernel. So I guess we have at several years worth. Over to you for the negative numbers. ;-) Thanx, Paul
With that patchset in mind, I am working on a really huge patch, which will greatly simplify the Linux kernel for the real problem of having that number of CPUs. That patch will have a lot of changes all over the architectures, so what will be the best way to post it? Should I split it architecture dependend and into one generic part. Currently it is a large blob of millions of changes, but will greatly simplify the Linux kernel. Regards, Lorenz Kolb Am 31.03.2012 23:21, schrieb Paul E. McKenney: > On Sat, Mar 31, 2012 at 11:00:08PM +0200, Eric Dumazet wrote: > >> On Sun, 2012-04-01 at 00:33 +0800, Paul E. McKenney wrote: >> >>> Although there have been numerous complaints about the complexity of >>> parallel programming (especially over the past 5-10 years), the plain >>> truth is that the incremental complexity of parallel programming over >>> that of sequential programming is not as large as is commonly believed. >>> Despite that you might have heard, the mind-numbing complexity of modern >>> computer systems is not due so much to there being multiple CPUs, but >>> rather to there being any CPUs at all. In short, for the ultimate in >>> computer-system simplicity, the optimal choice is NR_CPUS=0. >>> >>> This commit therefore limits kernel builds to zero CPUs. This change >>> has the beneficial side effect of rendering all kernel bugs harmless. >>> Furthermore, this commit enables additional beneficial changes, for >>> example, the removal of those parts of the kernel that are not needed >>> when there are zero CPUs. >>> >>> Signed-off-by: Paul E. McKenney<paulmck@linux.vnet.ibm.com> >>> Reviewed-by: Thomas Gleixner<tglx@linutronix.de> >>> --- >>> >> Hmm... I believe you could go one step forward and allow negative values >> as well. Antimatter was proven to exist after all. >> >> Hint : nr_cpu_ids is an "int", not an "unsigned int" >> >> Bonus: Existing bugs become "must have" features. >> > ;-) ;-) ;-) > > >> Of course there is no hurry and this can wait 365 days. >> > James Bottomley suggested imaginary numbers of CPUs some time back, > and I suppose there is no reason you cannot have fractional numbers of > CPUs, and perhaps irrational numbers as well. Of course, these last two > would require use of floating-point arithmetic (or something similar) > in the kernel. So I guess we have at several years worth. Over to you > for the negative numbers. ;-) > > Thanx, Paul > > _______________________________________________ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev >
On Sun, Apr 01, 2012 at 12:33:21AM +0800, Paul E. McKenney wrote: > Although there have been numerous complaints about the complexity of > parallel programming (especially over the past 5-10 years), the plain > truth is that the incremental complexity of parallel programming over > that of sequential programming is not as large as is commonly believed. > Despite that you might have heard, the mind-numbing complexity of modern > computer systems is not due so much to there being multiple CPUs, but > rather to there being any CPUs at all. In short, for the ultimate in > computer-system simplicity, the optimal choice is NR_CPUS=0. > > This commit therefore limits kernel builds to zero CPUs. This change > has the beneficial side effect of rendering all kernel bugs harmless. > Furthermore, this commit enables additional beneficial changes, for > example, the removal of those parts of the kernel that are not needed > when there are zero CPUs. > > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> > Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Great work, but I don't think you've gone far enough with this. What would really help is if you could consolidate all these NR_CPUS definitions into one place so we don't have essentially the same thing scattered across all these architectures. We're already doing this on ARM across our platforms, and its about time such an approach was taken across the entire kernel tree. It looks like the MIPS solution would be the best one to pick. Could you rework your patch to do this please? While you're at it, you might like to consider that having zero CPUs makes all this architecture support redundant, so maybe you've missed a trick there - according to my count, we could get rid of almost 3 million lines of code from arch. We could replace all that with a single standard implementation. Bah, maybe I shouldn't have pushed that bpf_jit code for ARM after all...
On Sun, Apr 01, 2012 at 12:19:25AM +0200, Lorenz Kolb wrote: > With that patchset in mind, I am working on a really huge patch, > which will greatly simplify the Linux kernel for the real problem > of having that number of CPUs. > > That patch will have a lot of changes all over the architectures, so > what will be the best way to post it? Should I split it architecture > dependend and into one generic part. > > Currently it is a large blob of millions of changes, but will > greatly simplify the Linux kernel. Perhaps a branch on a public git tree? If you are doing what I suspect you are, you will end up with a very large patch set. ;-) Thanx, Paul > Regards, > > Lorenz Kolb > > Am 31.03.2012 23:21, schrieb Paul E. McKenney: > >On Sat, Mar 31, 2012 at 11:00:08PM +0200, Eric Dumazet wrote: > >>On Sun, 2012-04-01 at 00:33 +0800, Paul E. McKenney wrote: > >>>Although there have been numerous complaints about the complexity of > >>>parallel programming (especially over the past 5-10 years), the plain > >>>truth is that the incremental complexity of parallel programming over > >>>that of sequential programming is not as large as is commonly believed. > >>>Despite that you might have heard, the mind-numbing complexity of modern > >>>computer systems is not due so much to there being multiple CPUs, but > >>>rather to there being any CPUs at all. In short, for the ultimate in > >>>computer-system simplicity, the optimal choice is NR_CPUS=0. > >>> > >>>This commit therefore limits kernel builds to zero CPUs. This change > >>>has the beneficial side effect of rendering all kernel bugs harmless. > >>>Furthermore, this commit enables additional beneficial changes, for > >>>example, the removal of those parts of the kernel that are not needed > >>>when there are zero CPUs. > >>> > >>>Signed-off-by: Paul E. McKenney<paulmck@linux.vnet.ibm.com> > >>>Reviewed-by: Thomas Gleixner<tglx@linutronix.de> > >>>--- > >>Hmm... I believe you could go one step forward and allow negative values > >>as well. Antimatter was proven to exist after all. > >> > >>Hint : nr_cpu_ids is an "int", not an "unsigned int" > >> > >>Bonus: Existing bugs become "must have" features. > >;-) ;-) ;-) > > > >>Of course there is no hurry and this can wait 365 days. > >James Bottomley suggested imaginary numbers of CPUs some time back, > >and I suppose there is no reason you cannot have fractional numbers of > >CPUs, and perhaps irrational numbers as well. Of course, these last two > >would require use of floating-point arithmetic (or something similar) > >in the kernel. So I guess we have at several years worth. Over to you > >for the negative numbers. ;-) > > > > Thanx, Paul > > > >_______________________________________________ > >Linuxppc-dev mailing list > >Linuxppc-dev@lists.ozlabs.org > >https://lists.ozlabs.org/listinfo/linuxppc-dev >
On Sat, Mar 31, 2012 at 11:32:00PM +0100, Russell King - ARM Linux wrote: > On Sun, Apr 01, 2012 at 12:33:21AM +0800, Paul E. McKenney wrote: > > Although there have been numerous complaints about the complexity of > > parallel programming (especially over the past 5-10 years), the plain > > truth is that the incremental complexity of parallel programming over > > that of sequential programming is not as large as is commonly believed. > > Despite that you might have heard, the mind-numbing complexity of modern > > computer systems is not due so much to there being multiple CPUs, but > > rather to there being any CPUs at all. In short, for the ultimate in > > computer-system simplicity, the optimal choice is NR_CPUS=0. > > > > This commit therefore limits kernel builds to zero CPUs. This change > > has the beneficial side effect of rendering all kernel bugs harmless. > > Furthermore, this commit enables additional beneficial changes, for > > example, the removal of those parts of the kernel that are not needed > > when there are zero CPUs. > > > > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> > > Reviewed-by: Thomas Gleixner <tglx@linutronix.de> > > Great work, but I don't think you've gone far enough with this. > > What would really help is if you could consolidate all these NR_CPUS > definitions into one place so we don't have essentially the same thing > scattered across all these architectures. We're already doing this on > ARM across our platforms, and its about time such an approach was taken > across the entire kernel tree. > > It looks like the MIPS solution would be the best one to pick. > Could you rework your patch to do this please? > > While you're at it, you might like to consider that having zero CPUs > makes all this architecture support redundant, so maybe you've missed > a trick there - according to my count, we could get rid of almost 3 > million lines of code from arch. We could replace all that with a > single standard implementation. > > Bah, maybe I shouldn't have pushed that bpf_jit code for ARM after all... ;-) ;-) ;-) Thanx, Paul
On Sun, Apr 01, 2012 at 12:33:21AM +0800, Paul E. McKenney wrote: > Although there have been numerous complaints about the complexity of > parallel programming (especially over the past 5-10 years), the plain > truth is that the incremental complexity of parallel programming over > that of sequential programming is not as large as is commonly believed. > Despite that you might have heard, the mind-numbing complexity of modern > computer systems is not due so much to there being multiple CPUs, but > rather to there being any CPUs at all. In short, for the ultimate in > computer-system simplicity, the optimal choice is NR_CPUS=0. > > This commit therefore limits kernel builds to zero CPUs. This change > has the beneficial side effect of rendering all kernel bugs harmless. > Furthermore, this commit enables additional beneficial changes, for > example, the removal of those parts of the kernel that are not needed > when there are zero CPUs. > > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> > Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Looks good, thanks for doing that. Btw, I just got confirmation from hw folk that we can actually give you hardware support for that code with an upcoming CPU which has NR_CPUS=0 cores. Oh, and additionally, we can disable some of those so getting into the negative is also doable from the hw perspective, so feel free to explore that side of the problem too. ACK.
On Sun, Apr 01, 2012 at 12:04:48PM +0200, Borislav Petkov wrote: > On Sun, Apr 01, 2012 at 12:33:21AM +0800, Paul E. McKenney wrote: > > Although there have been numerous complaints about the complexity of > > parallel programming (especially over the past 5-10 years), the plain > > truth is that the incremental complexity of parallel programming over > > that of sequential programming is not as large as is commonly believed. > > Despite that you might have heard, the mind-numbing complexity of modern > > computer systems is not due so much to there being multiple CPUs, but > > rather to there being any CPUs at all. In short, for the ultimate in > > computer-system simplicity, the optimal choice is NR_CPUS=0. > > > > This commit therefore limits kernel builds to zero CPUs. This change > > has the beneficial side effect of rendering all kernel bugs harmless. > > Furthermore, this commit enables additional beneficial changes, for > > example, the removal of those parts of the kernel that are not needed > > when there are zero CPUs. > > > > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> > > Reviewed-by: Thomas Gleixner <tglx@linutronix.de> > > Looks good, thanks for doing that. > > Btw, I just got confirmation from hw folk that we can actually give you > hardware support for that code with an upcoming CPU which has NR_CPUS=0 > cores. > > Oh, and additionally, we can disable some of those so getting into the > negative is also doable from the hw perspective, so feel free to explore > that side of the problem too. > > ACK. Cute! ;-) Thanx, Paul
diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig index 56a4df9..1766b4a 100644 --- a/arch/alpha/Kconfig +++ b/arch/alpha/Kconfig @@ -541,14 +541,15 @@ config HAVE_DEC_LOCK default y config NR_CPUS - int "Maximum number of CPUs (2-32)" - range 2 32 + int "Maximum number of CPUs (0-0)" + range 0 0 depends on SMP - default "32" if ALPHA_GENERIC || ALPHA_MARVEL - default "4" if !ALPHA_GENERIC && !ALPHA_MARVEL + default "0" if ALPHA_GENERIC || ALPHA_MARVEL + default "0" if !ALPHA_GENERIC && !ALPHA_MARVEL help MARVEL support can handle a maximum of 32 CPUs, all the others - with working support have a maximum of 4 CPUs. + with working support have a maximum of 4 CPUs. But why take + chances? Just stick with zero CPUs. config ARCH_DISCONTIGMEM_ENABLE bool "Discontiguous Memory Support (EXPERIMENTAL)" diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index a48aecc..1f07a3a 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1551,10 +1551,10 @@ config PAGE_OFFSET default 0xC0000000 config NR_CPUS - int "Maximum number of CPUs (2-32)" - range 2 32 + int "Maximum number of CPUs (0-0)" + range 0 0 depends on SMP - default "4" + default "0" config HOTPLUG_CPU bool "Support for hot-pluggable CPUs (EXPERIMENTAL)" diff --git a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig index abe5a9e..6a78549 100644 --- a/arch/blackfin/Kconfig +++ b/arch/blackfin/Kconfig @@ -241,7 +241,8 @@ config SMP config NR_CPUS int depends on SMP - default 2 if BF561 + range 0 0 + default 0 if BF561 config HOTPLUG_CPU bool "Support for hot-pluggable CPUs" diff --git a/arch/hexagon/Kconfig b/arch/hexagon/Kconfig index 9059e39..daab009 100644 --- a/arch/hexagon/Kconfig +++ b/arch/hexagon/Kconfig @@ -158,13 +158,14 @@ config SMP config NR_CPUS int "Maximum number of CPUs" if SMP - range 2 6 if SMP - default "1" if !SMP - default "6" if SMP + range 0 0 if SMP + default "0" if !SMP + default "0" if SMP ---help--- This allows you to specify the maximum number of CPUs which this kernel will support. The maximum supported value is 6 and the - minimum value which makes sense is 2. + minimum value which makes sense is 2. But a limit of zero is + so much safer! This is purely to save memory - each supported CPU adds approximately eight kilobytes to the kernel image. diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig index bd72669..fea0e6d 100644 --- a/arch/ia64/Kconfig +++ b/arch/ia64/Kconfig @@ -373,16 +373,17 @@ config SMP If you don't know what to do here, say N. config NR_CPUS - int "Maximum number of CPUs (2-4096)" - range 2 4096 + int "Maximum number of CPUs (0-0)" + range 0 0 depends on SMP - default "4096" + default "0" help You should set this to the number of CPUs in your system, but keep in mind that a kernel compiled for, e.g., 2 CPUs will boot but only use 2 CPUs on a >2 CPU system. Setting this to a value larger than 64 will cause the use of a CPU mask array, causing a small - performance hit. + performance hit. And setting it larger than zero risks all + manner of software bugs, so we just play it safe. config HOTPLUG_CPU bool "Support for hot-pluggable CPUs (EXPERIMENTAL)" diff --git a/arch/m32r/Kconfig b/arch/m32r/Kconfig index ef80a65..68b9e88 100644 --- a/arch/m32r/Kconfig +++ b/arch/m32r/Kconfig @@ -300,14 +300,16 @@ config CHIP_M32700_TS1 default n config NR_CPUS - int "Maximum number of CPUs (2-32)" - range 2 32 + int "Maximum number of CPUs (0-0)" + range 0 0 depends on SMP - default "2" + default "0" help This allows you to specify the maximum number of CPUs which this kernel will support. The maximum supported value is 32 and the - minimum value which makes sense is 2. + minimum value which makes sense is 2. Zero may not make sense, + but given that there is much in this world that does not make + sense, zero it is! This is purely to save memory - each supported CPU adds approximately eight kilobytes to the kernel image. diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 5ab6e89..3d7d06c 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -2192,16 +2192,16 @@ config NR_CPUS_DEFAULT_64 bool config NR_CPUS - int "Maximum number of CPUs (2-64)" - range 1 64 if NR_CPUS_DEFAULT_1 + int "Maximum number of CPUs (0-0)" + range 0 0 if NR_CPUS_DEFAULT_1 depends on SMP - default "1" if NR_CPUS_DEFAULT_1 - default "2" if NR_CPUS_DEFAULT_2 - default "4" if NR_CPUS_DEFAULT_4 - default "8" if NR_CPUS_DEFAULT_8 - default "16" if NR_CPUS_DEFAULT_16 - default "32" if NR_CPUS_DEFAULT_32 - default "64" if NR_CPUS_DEFAULT_64 + default "0" if NR_CPUS_DEFAULT_1 + default "0" if NR_CPUS_DEFAULT_2 + default "0" if NR_CPUS_DEFAULT_4 + default "0" if NR_CPUS_DEFAULT_8 + default "0" if NR_CPUS_DEFAULT_16 + default "0" if NR_CPUS_DEFAULT_32 + default "0" if NR_CPUS_DEFAULT_64 help This allows you to specify the maximum number of CPUs which this kernel will support. The maximum supported value is 32 for 32-bit @@ -2212,7 +2212,8 @@ config NR_CPUS This is purely to save memory - each supported CPU adds approximately eight kilobytes to the kernel image. For best performance should round up your number of processors to the next - power of two. + power of two. And just think how much more memory we will + save by setting the limit to zero! source "kernel/time/Kconfig" diff --git a/arch/mn10300/Kconfig b/arch/mn10300/Kconfig index 8f1c40d..85fc112 100644 --- a/arch/mn10300/Kconfig +++ b/arch/mn10300/Kconfig @@ -201,7 +201,8 @@ config SMP config NR_CPUS int depends on SMP - default "2" + range 0 0 + default "0" source "kernel/Kconfig.preempt" diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig index 242a1b7..358eaf8 100644 --- a/arch/parisc/Kconfig +++ b/arch/parisc/Kconfig @@ -254,10 +254,10 @@ config HPUX depends on !64BIT config NR_CPUS - int "Maximum number of CPUs (2-32)" - range 2 32 + int "Maximum number of CPUs (0-0)" + range 0 0 depends on SMP - default "32" + default "0" endmenu diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype index 425db18..5e607e0 100644 --- a/arch/powerpc/platforms/Kconfig.cputype +++ b/arch/powerpc/platforms/Kconfig.cputype @@ -356,11 +356,11 @@ config SMP If you don't know what to do here, say N. config NR_CPUS - int "Maximum number of CPUs (2-8192)" - range 2 8192 + int "Maximum number of CPUs (0-0)" + range 0 0 depends on SMP - default "32" if PPC64 - default "4" + default "0" if PPC64 + default "0" config NOT_COHERENT_CACHE bool diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig index d172758..f9bc067 100644 --- a/arch/s390/Kconfig +++ b/arch/s390/Kconfig @@ -169,15 +169,17 @@ config SMP Even if you don't know what to do here, say Y. config NR_CPUS - int "Maximum number of CPUs (2-64)" - range 2 64 + int "Maximum number of CPUs (0-0)" + range 0 0 depends on SMP - default "32" if !64BIT - default "64" if 64BIT + default "0" if !64BIT + default "0" if 64BIT help This allows you to specify the maximum number of CPUs which this kernel will support. The maximum supported value is 64 and the - minimum value which makes sense is 2. + minimum value which makes sense is 2. The minimal value that + makes sense might well be 2, but we all know that the only + -sane- value is zero! This is purely to save memory - each supported CPU adds approximately sixteen kilobytes to the kernel image. diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig index 713fb58..5ddc7c0 100644 --- a/arch/sh/Kconfig +++ b/arch/sh/Kconfig @@ -705,18 +705,19 @@ config SMP If you don't know what to do here, say N. config NR_CPUS - int "Maximum number of CPUs (2-32)" - range 2 32 + int "Maximum number of CPUs (0-0)" + range 0 0 depends on SMP - default "4" if CPU_SUBTYPE_SHX3 - default "2" + default "0" if CPU_SUBTYPE_SHX3 + default "0" help This allows you to specify the maximum number of CPUs which this kernel will support. The maximum supported value is 32 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. + approximately eight kilobytes to the kernel image. Debloating + is the way, NR_CPUS to zero today!!! config HOTPLUG_CPU bool "Support for hot-pluggable CPUs (EXPERIMENTAL)" diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig index ca5580e..0de9f0f 100644 --- a/arch/sparc/Kconfig +++ b/arch/sparc/Kconfig @@ -177,10 +177,10 @@ config SMP config NR_CPUS int "Maximum number of CPUs" depends on SMP - range 2 32 if SPARC32 - range 2 1024 if SPARC64 - default 32 if SPARC32 - default 64 if SPARC64 + range 0 0 if SPARC32 + range 0 0 if SPARC64 + default 0 if SPARC32 + default 0 if SPARC64 source kernel/Kconfig.hz diff --git a/arch/tile/Kconfig b/arch/tile/Kconfig index 11270ca..a05112c 100644 --- a/arch/tile/Kconfig +++ b/arch/tile/Kconfig @@ -126,14 +126,15 @@ source "init/Kconfig" menu "Tilera-specific configuration" config NR_CPUS - int "Maximum number of tiles (2-255)" - range 2 255 + int "Maximum number of tiles (0-0)" + range 0 0 depends on SMP - default "64" + default "0" ---help--- Building with 64 is the recommended value, but a slightly smaller kernel memory footprint results from using a smaller - value on chips with fewer tiles. + value on chips with fewer tiles. To minimize both memory + footprint and bugs, use zero and only zero. source "kernel/time/Kconfig" diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 5bed94e..a6977f2 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -773,19 +773,21 @@ config MAXSMP config NR_CPUS int "Maximum number of CPUs" if SMP && !MAXSMP - range 2 8 if SMP && X86_32 && !X86_BIGSMP - range 2 512 if SMP && !MAXSMP - default "1" if !SMP - default "4096" if MAXSMP - default "32" if SMP && (X86_NUMAQ || X86_SUMMIT || X86_BIGSMP || X86_ES7000) - default "8" if SMP + range 0 0 if SMP && X86_32 && !X86_BIGSMP + range 0 0 if SMP && !MAXSMP + default "0" if !SMP + default "0" if MAXSMP + default "0" if SMP && (X86_NUMAQ || X86_SUMMIT || X86_BIGSMP || X86_ES7000) + default "0" if SMP ---help--- This allows you to specify the maximum number of CPUs which this 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. + approximately eight kilobytes to the kernel image. But + the first supported CPU brings a lot of bugs with it, so + for ultimate reliability, set the number of CPUs to zero. config SCHED_SMT bool "SMT (Hyperthreading) scheduler support"