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