Simplify the Linux kernel by reducing its state space

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 <[email protected]>

Reviewed-by Thomas Gleixner <[email protected]>

---

 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(-)

Hi Paul,

Quoted 34 lines · Paul E. McKenney

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 <[email protected]>

Reviewed-by Thomas Gleixner <[email protected]>

---

 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 +++++++++-------

Quoted 1 line

 15 files changed, 78 insertions(+), 64 deletions(-)

You forgot to fix half of the architectures, a.o. m68k?

Hi Paul,

Quoted 34 lines · Paul E. McKenney

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 <[email protected]>

Reviewed-by Thomas Gleixner <[email protected]>

---

 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 +++++++++-------

Quoted 1 line

 15 files changed, 78 insertions(+), 64 deletions(-)

You forgot to fix half of the architectures, a.o. m68k?

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 <[email protected]>

Reviewed-by Thomas Gleixner <[email protected]>

---

 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(-)

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 <[email protected]>

Reviewed-by Thomas Gleixner <[email protected]>

---

 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(-)

arch/alpha/Kconfig +6 -5

index 56a4df9..1766b4a 100644
@@ -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)"

arch/arm/Kconfig +3 -3

index a48aecc..1f07a3a 100644
@@ -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)"

arch/blackfin/Kconfig +2 -1

index abe5a9e..6a78549 100644
@@ -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"

arch/hexagon/Kconfig +5 -4

index 9059e39..daab009 100644
@@ -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.

arch/ia64/Kconfig +3 -3

index bd72669..fea0e6d 100644
@@ -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

arch/ia64/Kconfig +2 -1

-         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)"

arch/m32r/Kconfig +6 -4

index ef80a65..68b9e88 100644
@@ -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.

arch/mips/Kconfig +11 -10

index 5ab6e89..3d7d06c 100644
@@ -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"
 

arch/mn10300/Kconfig +2 -1

index 8f1c40d..85fc112 100644
@@ -201,7 +201,8 @@ config SMP
 config NR_CPUS
       int
       depends on SMP
-       default "2"
+       range 0 0
+       default "0"
 
 source "kernel/Kconfig.preempt"
 

arch/parisc/Kconfig +3 -3

index 242a1b7..358eaf8 100644
@@ -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
 

arch/powerpc/platforms/Kconfig.cputype +4 -4

index 425db18..5e607e0 100644
@@ -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

arch/s390/Kconfig +7 -5

index d172758..f9bc067 100644
@@ -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.

arch/sh/Kconfig +6 -5

index 713fb58..5ddc7c0 100644
@@ -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)"

arch/sparc/Kconfig +4 -4

index ca5580e..0de9f0f 100644
@@ -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
 

arch/tile/Kconfig +5 -4

index 11270ca..a05112c 100644
@@ -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"
 

arch/x86/Kconfig +9 -7

index 5bed94e..a6977f2 100644
@@ -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 [email protected]
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 that Paul is a trustworthy programmer.
Thus, please add my ack

Ack'ed by: Linas Vepstas <[email protected]>

Quoted 403 lines

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 <[email protected]>

Reviewed-by Thomas Gleixner <[email protected]>

---

 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(-)

arch/alpha/Kconfig +6 -5

index 56a4df9..1766b4a 100644
@@ -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)"

arch/arm/Kconfig +3 -3

index a48aecc..1f07a3a 100644
@@ -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)"

arch/blackfin/Kconfig +2 -1

index abe5a9e..6a78549 100644
@@ -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"

arch/hexagon/Kconfig +5 -4

index 9059e39..daab009 100644
@@ -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.

arch/ia64/Kconfig +3 -3

index bd72669..fea0e6d 100644
@@ -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

arch/ia64/Kconfig +2 -1

-         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)"

arch/m32r/Kconfig +6 -4

index ef80a65..68b9e88 100644
@@ -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.

arch/mips/Kconfig +11 -10

index 5ab6e89..3d7d06c 100644
@@ -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"
 

arch/mn10300/Kconfig +2 -1

index 8f1c40d..85fc112 100644
@@ -201,7 +201,8 @@ config SMP
 config NR_CPUS
       int
       depends on SMP
-       default "2"
+       range 0 0
+       default "0"
 
 source "kernel/Kconfig.preempt"
 

arch/parisc/Kconfig +3 -3

index 242a1b7..358eaf8 100644
@@ -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
 

arch/powerpc/platforms/Kconfig.cputype +4 -4

index 425db18..5e607e0 100644
@@ -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

arch/s390/Kconfig +7 -5

index d172758..f9bc067 100644
@@ -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.

arch/sh/Kconfig +6 -5

index 713fb58..5ddc7c0 100644
@@ -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)"

arch/sparc/Kconfig +4 -4

index ca5580e..0de9f0f 100644
@@ -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
 

arch/tile/Kconfig +5 -4

index 11270ca..a05112c 100644
@@ -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"
 

arch/x86/Kconfig +9 -7

index 5bed94e..a6977f2 100644
@@ -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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

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 <[email protected]>

Reviewed-by Thomas Gleixner <[email protected]>

---

 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(-)

arch/alpha/Kconfig +6 -5

index 56a4df9..1766b4a 100644
@@ -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)"

arch/arm/Kconfig +3 -3

index a48aecc..1f07a3a 100644
@@ -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)"

arch/blackfin/Kconfig +2 -1

index abe5a9e..6a78549 100644
@@ -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"

arch/hexagon/Kconfig +5 -4

index 9059e39..daab009 100644
@@ -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.

arch/ia64/Kconfig +5 -4

index bd72669..fea0e6d 100644
@@ -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)"

arch/m32r/Kconfig +6 -4

index ef80a65..68b9e88 100644
@@ -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.

arch/mips/Kconfig +11 -10

index 5ab6e89..3d7d06c 100644
@@ -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"
 

arch/mn10300/Kconfig +2 -1

index 8f1c40d..85fc112 100644
@@ -201,7 +201,8 @@ config SMP
 config NR_CPUS
 	int
 	depends on SMP
-	default "2"
+	range 0 0
+	default "0"
 
 source "kernel/Kconfig.preempt"
 

arch/parisc/Kconfig +3 -3

index 242a1b7..358eaf8 100644
@@ -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
 

arch/powerpc/platforms/Kconfig.cputype +4 -4

index 425db18..5e607e0 100644
@@ -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

arch/s390/Kconfig +7 -5

index d172758..f9bc067 100644
@@ -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.

arch/sh/Kconfig +6 -5

index 713fb58..5ddc7c0 100644
@@ -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)"

arch/sparc/Kconfig +4 -4

index ca5580e..0de9f0f 100644
@@ -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
 

arch/tile/Kconfig +5 -4

index 11270ca..a05112c 100644
@@ -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"
 

arch/x86/Kconfig +9 -8

index 5bed94e..a6977f2 100644
@@ -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 [email protected]
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.

Quoted 3 lines · Linas Vepstas

Hi,

Quoted 5 lines

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.

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 <[email protected]>

Reviewed-by Thomas Gleixner <[email protected]>

---

Quoted 15 lines · Paul E. McKenney

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.

Quoted 3 lines

Signed-off-by Paul E. McKenney <[email protected]>

Reviewed-by Thomas Gleixner <[email protected]>

---

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.

Quoted 22 lines · Paul E. McKenney

Quoted 16 lines

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.

Quoted 4 lines

Signed-off-by Paul E. McKenney<[email protected]>

Reviewed-by Thomas Gleixner<[email protected]>

---

Quoted 7 lines

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.

;-) ;-) ;-)

Quoted 2 lines

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
[email protected]
https://lists.ozlabs.org/listinfo/linuxppc-dev

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:

Quoted 42 lines · Eric Dumazet

Quoted 19 lines · Paul E. McKenney

Quoted 15 lines

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.

Quoted 3 lines

Signed-off-by Paul E. McKenney<[email protected]>

Reviewed-by Thomas Gleixner<[email protected]>

---

Quoted 6 lines

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.

;-) ;-) ;-)

Quoted 1 line

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
[email protected]
https://lists.ozlabs.org/listinfo/linuxppc-dev

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 <[email protected]>

Reviewed-by Thomas Gleixner <[email protected]>

Quoted 9 lines · Paul E. McKenney

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.

Quoted 8 lines

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 <[email protected]>

Reviewed-by Thomas Gleixner <[email protected]>

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...

Quoted 9 lines · Paul E. McKenney

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.

Quoted 8 lines

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 <[email protected]>

Reviewed-by Thomas Gleixner <[email protected]>

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.

Quoted 27 lines · Russell King - ARM Linux

Quoted 9 lines · Paul E. McKenney

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.

Quoted 8 lines

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 <[email protected]>

Reviewed-by Thomas Gleixner <[email protected]>

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.

Quoted 8 lines

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.

For a first step we can deprecated arch/ and make it depend on CONFIG_STAGING. That way we can have it around a bit for sentimental reasons w/o having a lot of churn.

Suggested-by Russell King <[email protected]>

Signed-off-by Thomas Gleixner <[email protected]>

Index: tip/Makefile
===================================================================

Makefile +2 -0

@@ -564,7 +564,9 @@ else
 KBUILD_CFLAGS	+= -O2
 endif
 
+ifdef CONFIG_ARCH_SUPPORT
 include $(srctree)/arch/$(SRCARCH)/Makefile
+endif
 
 ifneq ($(CONFIG_FRAME_WARN),0)
 KBUILD_CFLAGS += $(call cc-option,-Wframe-larger-than=${CONFIG_FRAME_WARN})

Index: tip/drivers/staging/Kconfig
===================================================================

drivers/staging/Kconfig +4 -0

@@ -1,6 +1,10 @@
+config ARCH_SUPPORT
+	bool
+
 menuconfig STAGING
 	bool "Staging drivers"
 	default n
+	select ARCH_SUPPORT
 	---help---
 	  This option allows you to select a number of drivers that are
 	  not of the "normal" Linux kernel quality level.  These drivers

Index: tip/Documentation/feature-removal-schedule.txt
===================================================================

Documentation/feature-removal-schedule.txt +10 -0

@@ -537,3 +537,13 @@ When:	3.6
 Why:	setitimer is not returning -EFAULT if user pointer is NULL. This
 	violates the spec.
 Who:	Sasikantha Babu <[email protected]>
+
+-----------------------------
+
+What:	Remove arch
+When:	April 1st 2013
+Why:    NR_CPUS=0 made arch/ obsolete. Keep it around a bit for
+	sentimental reasons.
+Who:	paulmck,tglx.rmk
+
+	

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 <[email protected]>

Reviewed-by Thomas Gleixner <[email protected]>

Quoted 9 lines · Paul E. McKenney

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.

Quoted 8 lines

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 <[email protected]>

Reviewed-by Thomas Gleixner <[email protected]>

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.