[PATCH RFC] 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 <redacted>
Reviewed-by: Thomas Gleixner <redacted>
---

 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"

Hi Paul,

On Sat, Mar 31, 2012 at 18:33, Paul E. McKenney
[off-list ref] 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 <redacted>
Reviewed-by: Thomas Gleixner <redacted>
---

?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 at 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
[off-list ref] wrote:

quoted

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 <redacted>
Reviewed-by: Thomas Gleixner <redacted>
---

?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 Paul.  And I've heard of
Thomas Gleixner.

Thus, please add my ack --

Ack'ed by: Linas Vepstas [off-list ref]


On Sun, Apr 01, 2012 at 12:33:21AM +0800, Paul E. McKenney was heard to remark:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120331/a9346d5a/attachment-0001.sig>

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.

-- 
~Randy

On Sat, Mar 31, 2012 at 01:25:02PM -0700, Randy Dunlap wrote:

On 03/31/2012 01:15 PM, Linas Vepstas wrote:

quoted

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 <redacted>
Reviewed-by: Thomas Gleixner <redacted>
---

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:

quoted

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 <redacted>
Reviewed-by: Thomas Gleixner <redacted>
---

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:
   

quoted

On Sun, 2012-04-01 at 00:33 +0800, Paul E. McKenney wrote:
     

quoted

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<redacted>
Reviewed-by: Thomas Gleixner<redacted>
---
       

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

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 at lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
   

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:

quoted

On Sat, Mar 31, 2012 at 11:00:08PM +0200, Eric Dumazet wrote:

quoted

On Sun, 2012-04-01 at 00:33 +0800, Paul E. McKenney wrote:

quoted

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<redacted>
Reviewed-by: Thomas Gleixner<redacted>
---

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

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 at 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 <redacted>
Reviewed-by: Thomas Gleixner <redacted>

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

quoted

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 <redacted>
Reviewed-by: Thomas Gleixner <redacted>

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 Sat, 31 Mar 2012, Russell King - ARM Linux wrote:

On Sun, Apr 01, 2012 at 12:33:21AM +0800, Paul E. McKenney wrote:

quoted

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 <redacted>
Reviewed-by: Thomas Gleixner <redacted>

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.

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 <redacted>
Signed-off-by: Thomas Gleixner <redacted>

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

--- tip.orig/Makefile
+++ tip/Makefile

@@ -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
===================================================================

--- tip.orig/drivers/staging/Kconfig
+++ tip/drivers/staging/Kconfig

@@ -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
===================================================================

--- tip.orig/Documentation/feature-removal-schedule.txt
+++ tip/Documentation/feature-removal-schedule.txt

@@ -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 <sasikanth.v19@gmail.com>
+
+-----------------------------
+
+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
+
+	

On Sun, Apr 01, 2012 at 07:34:55PM +0200, Thomas Gleixner wrote:

On Sat, 31 Mar 2012, Russell King - ARM Linux wrote:

quoted

On Sun, Apr 01, 2012 at 12:33:21AM +0800, Paul E. McKenney wrote:

quoted

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 <redacted>
Reviewed-by: Thomas Gleixner <redacted>

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.

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 <redacted>
Signed-off-by: Thomas Gleixner <redacted>

;-) ;-) ;-)

Reviewed-by: Paul E. McKenney <redacted>

							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 <redacted>
Reviewed-by: Thomas Gleixner <redacted>

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.

-- 
Regards/Gruss,
    Boris.

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:

quoted

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 <redacted>
Reviewed-by: Thomas Gleixner <redacted>

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