* Re: [PATCH] Bug fix in commit 178db7d3 triggered a bug in the SPI driver for MPC83XX (pdata is NULL).
From: Joakim Tjernlund @ 2012-03-30 15:16 UTC (permalink / raw)
To: Kenth Eriksson; +Cc: spi-devel-general, linuxppc-dev
In-Reply-To: <1333119930-21129-1-git-send-email-kenth.eriksson@transmode.com>
Kenth Eriksson <kenth.eriksson@transmode.com> wrote on 2012/03/30 17:05:30:
>
> After commit 178db7d3 devices are initialized as children of the bus master, not children of the bus masters parent device. The pdata pointer used in fsl_spi_chipselect must updated to reflect the changed initialization.
>
> Signed-off-by: Kenth Eriksson <kenth.eriksson@transmode.com>
Acked-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
^ permalink raw reply
* [REGRESSION][PATCH V4 3/3] bpf jit: Let the powerpc jit handle negative offsets
From: Jan Seiffert @ 2012-03-30 15:35 UTC (permalink / raw)
To: netdev
Cc: Eric Dumazet, linuxppc-dev, linux-kernel, Matt Evans,
David S. Miller
In-Reply-To: <4F75CA89.4010709@googlemail.com>
Now the helper function from filter.c for negative offsets is exported,
it can be used it in the jit to handle negative offsets.
First modify the asm load helper functions to handle:
- know positive offsets
- know negative offsets
- any offset
then the compiler can be modified to explicitly use these helper
when appropriate.
This fixes the case of a negative X register and allows to lift
the restriction that bpf programs with negative offsets can't
be jited.
Signed-off-by: Jan Seiffert <kaffeemonster@googlemail.com>
I have only compile tested this, -ENOHARDWARE.
Can someone with more powerpc kung-fu review and maybe test this?
Esp. powerpc asm is not my strong point. I think i botched the
stack frame in the call setup. Help?
diff --git a/arch/powerpc/net/bpf_jit_64.S b/arch/powerpc/net/bpf_jit_64.S
index ff4506e..e590aa5 100644
--- a/arch/powerpc/net/bpf_jit_64.S
+++ b/arch/powerpc/net/bpf_jit_64.S
@@ -31,14 +31,13 @@
* then branch directly to slow_path_XXX if required. (In fact, could
* load a spare GPR with the address of slow_path_generic and pass size
* as an argument, making the call site a mtlr, li and bllr.)
- *
- * Technically, the "is addr < 0" check is unnecessary & slowing down
- * the ABS path, as it's statically checked on generation.
*/
.globl sk_load_word
sk_load_word:
cmpdi r_addr, 0
- blt bpf_error
+ blt bpf_slow_path_word_neg
+ .globl sk_load_word_positive_offset
+sk_load_word_positive_offset:
/* Are we accessing past headlen? */
subi r_scratch1, r_HL, 4
cmpd r_scratch1, r_addr
@@ -51,7 +50,9 @@ sk_load_word:
.globl sk_load_half
sk_load_half:
cmpdi r_addr, 0
- blt bpf_error
+ blt bpf_slow_path_half_neg
+ .globl sk_load_half_positive_offset
+sk_load_half_positive_offset:
subi r_scratch1, r_HL, 2
cmpd r_scratch1, r_addr
blt bpf_slow_path_half
@@ -61,7 +62,9 @@ sk_load_half:
.globl sk_load_byte
sk_load_byte:
cmpdi r_addr, 0
- blt bpf_error
+ blt bpf_slow_path_byte_neg
+ .globl sk_load_byte_positive_offset
+sk_load_byte_positive_offset:
cmpd r_HL, r_addr
ble bpf_slow_path_byte
lbzx r_A, r_D, r_addr
@@ -69,22 +72,20 @@ sk_load_byte:
/*
* BPF_S_LDX_B_MSH: ldxb 4*([offset]&0xf)
- * r_addr is the offset value, already known positive
+ * r_addr is the offset value
*/
.globl sk_load_byte_msh
sk_load_byte_msh:
+ cmpdi r_addr, 0
+ blt bpf_slow_path_byte_msh_neg
+ .globl sk_load_byte_msh_positive_offset
+sk_load_byte_msh_positive_offset:
cmpd r_HL, r_addr
ble bpf_slow_path_byte_msh
lbzx r_X, r_D, r_addr
rlwinm r_X, r_X, 2, 32-4-2, 31-2
blr
-bpf_error:
- /* Entered with cr0 = lt */
- li r3, 0
- /* Generated code will 'blt epilogue', returning 0. */
- blr
-
/* Call out to skb_copy_bits:
* We'll need to back up our volatile regs first; we have
* local variable space at r1+(BPF_PPC_STACK_BASIC).
@@ -136,3 +137,85 @@ bpf_slow_path_byte_msh:
lbz r_X, BPF_PPC_STACK_BASIC+(2*8)(r1)
rlwinm r_X, r_X, 2, 32-4-2, 31-2
blr
+
+/* Call out to bpf_internal_load_pointer_neg_helper:
+ * We'll need to back up our volatile regs first; we have
+ * local variable space at r1+(BPF_PPC_STACK_BASIC).
+ * Allocate a new stack frame here to remain ABI-compliant in
+ * stashing LR.
+ */
+#define sk_negative_common(SIZE) \
+ mflr r0; \
+ std r0, 16(r1); \
+ /* R3 goes in parameter space of caller's frame */ \
+ std r_skb, (BPF_PPC_STACKFRAME+48)(r1); \
+ std r_A, (BPF_PPC_STACK_BASIC+(0*8))(r1); \
+ std r_X, (BPF_PPC_STACK_BASIC+(1*8))(r1); \
+ stdu r1, -BPF_PPC_SLOWPATH_FRAME(r1); \
+ /* R3 = r_skb, as passed */ \
+ mr r4, r_addr; \
+ li r5, SIZE; \
+ bl bpf_internal_load_pointer_neg_helper; \
+ /* R3 != 0 on success */ \
+ addi r1, r1, BPF_PPC_SLOWPATH_FRAME; \
+ ld r0, 16(r1); \
+ ld r_A, (BPF_PPC_STACK_BASIC+(0*8))(r1); \
+ ld r_X, (BPF_PPC_STACK_BASIC+(1*8))(r1); \
+ mtlr r0; \
+ cmpldi r3, 0; \
+ beq bpf_error_slow; /* cr0 = EQ */ \
+ mr r_addr, r3; \
+ ld r_skb, (BPF_PPC_STACKFRAME+48)(r1); \
+ /* Great success! */
+
+bpf_slow_path_word_neg:
+ lis r_scratch1,-32 /* SKF_LL_OFF */
+ cmpd r_addr, r_scratch1 /* addr < SKF_* */
+ blt bpf_error /* cr0 = LT */
+ .globl sk_load_word_negative_offset
+sk_load_word_negative_offset:
+ sk_negative_common(4)
+ lwz r_A, 0(r_addr)
+ blr
+
+bpf_slow_path_half_neg:
+ lis r_scratch1,-32 /* SKF_LL_OFF */
+ cmpd r_addr, r_scratch1 /* addr < SKF_* */
+ blt bpf_error /* cr0 = LT */
+ .globl sk_load_half_negative_offset
+sk_load_half_negative_offset:
+ sk_negative_common(2)
+ lhz r_A, 0(r_addr)
+ blr
+
+bpf_slow_path_byte_neg:
+ lis r_scratch1,-32 /* SKF_LL_OFF */
+ cmpd r_addr, r_scratch1 /* addr < SKF_* */
+ blt bpf_error /* cr0 = LT */
+ .globl sk_load_byte_negative_offset
+sk_load_byte_negative_offset:
+ sk_negative_common(1)
+ lbz r_A, 0(r_addr)
+ blr
+
+bpf_slow_path_byte_msh_neg:
+ lis r_scratch1,-32 /* SKF_LL_OFF */
+ cmpd r_addr, r_scratch1 /* addr < SKF_* */
+ blt bpf_error /* cr0 = LT */
+ .globl sk_load_byte_msh_negative_offset
+sk_load_byte_msh_negative_offset:
+ sk_negative_common(1)
+ lbz r_X, 0(r_addr)
+ rlwinm r_X, r_X, 2, 32-4-2, 31-2
+ blr
+
+bpf_error_slow:
+ /* fabricate a cr0 = lt */
+ li r_scratch1, -1
+ cmpdi r_scratch1, 0
+bpf_error:
+ /* Entered with cr0 = lt */
+ li r3, 0
+ /* Generated code will 'blt epilogue', returning 0. */
+ blr
+
diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
index 73619d3..2dc8b14 100644
--- a/arch/powerpc/net/bpf_jit_comp.c
+++ b/arch/powerpc/net/bpf_jit_comp.c
@@ -127,6 +127,9 @@ static void bpf_jit_build_epilogue(u32 *image, struct codegen_context *ctx)
PPC_BLR();
}
+#define CHOOSE_LOAD_FUNC(K, func) \
+ ((int)K < 0 ? ((int)K >= SKF_LL_OFF ? func##_negative_offset : func) : func##_positive_offset)
+
/* Assemble the body code between the prologue & epilogue. */
static int bpf_jit_build_body(struct sk_filter *fp, u32 *image,
struct codegen_context *ctx,
@@ -391,21 +394,16 @@ static int bpf_jit_build_body(struct sk_filter *fp, u32 *image,
/*** Absolute loads from packet header/data ***/
case BPF_S_LD_W_ABS:
- func = sk_load_word;
+ func = CHOOSE_LOAD_FUNC(K, sk_load_word);
goto common_load;
case BPF_S_LD_H_ABS:
- func = sk_load_half;
+ func = CHOOSE_LOAD_FUNC(K, sk_load_half);
goto common_load;
case BPF_S_LD_B_ABS:
- func = sk_load_byte;
+ func = CHOOSE_LOAD_FUNC(K, sk_load_byte);
common_load:
- /*
- * Load from [K]. Reference with the (negative)
- * SKF_NET_OFF/SKF_LL_OFF offsets is unsupported.
- */
+ /* Load from [K]. */
ctx->seen |= SEEN_DATAREF;
- if ((int)K < 0)
- return -ENOTSUPP;
PPC_LI64(r_scratch1, func);
PPC_MTLR(r_scratch1);
PPC_LI32(r_addr, K);
@@ -429,7 +427,7 @@ static int bpf_jit_build_body(struct sk_filter *fp, u32 *image,
common_load_ind:
/*
* Load from [X + K]. Negative offsets are tested for
- * in the helper functions, and result in a 'ret 0'.
+ * in the helper functions.
*/
ctx->seen |= SEEN_DATAREF | SEEN_XREG;
PPC_LI64(r_scratch1, func);
@@ -443,13 +441,7 @@ static int bpf_jit_build_body(struct sk_filter *fp, u32 *image,
break;
case BPF_S_LDX_B_MSH:
- /*
- * x86 version drops packet (RET 0) when K<0, whereas
- * interpreter does allow K<0 (__load_pointer, special
- * ancillary data). common_load returns ENOTSUPP if K<0,
- * so we fall back to interpreter & filter works.
- */
- func = sk_load_byte_msh;
+ func = CHOOSE_LOAD_FUNC(K, sk_load_byte_msh);
goto common_load;
break;
^ permalink raw reply related
* [REGRESSION][PATCH V4 1/3] bpf jit: Make the filter.c::__load_pointer helper non-static for the jits
From: Jan Seiffert @ 2012-03-30 15:08 UTC (permalink / raw)
To: netdev
Cc: Eric Dumazet, linuxppc-dev, linux-kernel, Matt Evans,
David S. Miller
In-Reply-To: <4F75CA89.4010709@googlemail.com>
The function is renamed to make it a little more clear what it does.
It is not added to any .h because it is not for general consumption, only for
bpf internal use (and so by the jits).
Signed-of-by: Jan Seiffert <kaffeemonster@googlemail.com>
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -40,8 +40,12 @@
#include <linux/reciprocal_div.h>
#include <linux/ratelimit.h>
-/* No hurry in this branch */
-static void *__load_pointer(const struct sk_buff *skb, int k, unsigned int size)
+/*
+ * No hurry in this branch
+ *
+ * Exported for the bpf jit load helper.
+ */
+void *bpf_internal_load_pointer_neg_helper(const struct sk_buff *skb, int k, unsigned int size)
{
u8 *ptr = NULL;
@@ -60,7 +64,7 @@ static inline void *load_pointer(const struct sk_buff *skb, int k,
{
if (k >= 0)
return skb_header_pointer(skb, k, size, buffer);
- return __load_pointer(skb, k, size);
+ return bpf_internal_load_pointer_neg_helper(skb, k, size);
}
/**
^ permalink raw reply
* [REGRESSION][PATCH V4 0/3] bpf jit drops the ball on negative memory references
From: Jan Seiffert @ 2012-03-30 15:00 UTC (permalink / raw)
To: netdev
Cc: Eric Dumazet, linuxppc-dev, linux-kernel, Matt Evans,
David S. Miller
Consider the following test program:
#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <pcap-bpf.h>
#define die(x) do {perror(x); return 1;} while (0)
struct bpf_insn udp_filter[] = {
/* 0 */ BPF_STMT(BPF_LDX|BPF_W|BPF_IMM, -1048576+(0)), /* leax net[0] */
/* 1 */ BPF_STMT(BPF_LD|BPF_B|BPF_IND, 0), /* ldb [x+0] */
/* 2 */ BPF_STMT(BPF_RET|BPF_A, 0), /* ret a */
};
int main(int argc, char *argv[])
{
char buf[512];
struct sockaddr_in addr;
struct bpf_program prg;
socklen_t addr_s;
ssize_t res;
int fd;
addr.sin_family = AF_INET;
addr.sin_port = htons(5000);
addr.sin_addr.s_addr = 0;
addr_s = sizeof(addr);
prg.bf_len = sizeof(udp_filter)/sizeof(udp_filter[0]);
prg.bf_insns = udp_filter;
if(-1 == (fd = socket(AF_INET, SOCK_DGRAM, 0)))
die("socket");
if(-1 == bind(fd, (struct sockaddr *)&addr, sizeof(addr)))
die("bind");
if(-1 == setsockopt(fd, SOL_SOCKET, SO_ATTACH_FILTER, &prg, sizeof(prg)))
die("setsockopt");
res = recvfrom(fd, buf, sizeof(buf), 0, (struct sockaddr *)&addr, &addr_s);
if(res != -1)
printf("packet received: %zi bytes\n", res);
else
die("recvfrom");
return 0;
}
when used with the bpf jit disabled works:
console 1 $ ./bpf
console 2 $ echo "hello" | nc -u localhost 5000
console 1: packet received: 6 bytes
When the bpf jit gets enabled (echo 100 >
/proc/sys/net/core/bpf_jit_enable) the same program stops working:
console 1 $ ./bpf
console 2 $ echo "hello" | nc -u localhost 5000
console 1:
The reason is that both jits (x86 and powerpc) do not handle negative
memory references like SKF_NET_OFF or SKF_LL_OFF, only the simple
ancillary data references are supported (by mapping to special
instructions).
In the case of an absolute reference, the jit aborts the translation
if a negative reference is seen, also a negative k on the indirect
load aborts the translation, but if X is negative to begin with, only
the error handler is reached at runtime which drops the whole packet.
Such a setup is useful to say filter bogus source addresses on an UDP
socket.
I propose the following patch series to fix this situation.
Patch 1 exports the helper function the interpreter uses.
Patch 2 incorporates the helper into the x86 jit (so it depends on patch 1).
Patch 3 incorporates the helper into the powerpc jit (so it depends on patch 1).
Lightly tested on x86, but the powerpc asm part is prop. wrong, could
need assistance.
Signed-of-by: Jan Seiffert <kaffeemonster@googlemail.com>
^ permalink raw reply
* Re: [REGRESSION][PATCH V4 1/3] bpf jit: Make the filter.c::__load_pointer helper non-static for the jits
From: Eric Dumazet @ 2012-03-30 18:56 UTC (permalink / raw)
To: Jan Seiffert
Cc: netdev, linuxppc-dev, linux-kernel, Matt Evans, David S. Miller
In-Reply-To: <4F75CC63.10405@googlemail.com>
On Fri, 2012-03-30 at 17:08 +0200, Jan Seiffert wrote:
> The function is renamed to make it a little more clear what it does.
> It is not added to any .h because it is not for general consumption, only for
> bpf internal use (and so by the jits).
>
> Signed-of-by: Jan Seiffert <kaffeemonster@googlemail.com>
>
Missing "---" line separator (check Documentation/SubmittingPatches line
490)
You can check http://patchwork.ozlabs.org/patch/149683/ and see there is
a problem, compared to http://patchwork.ozlabs.org/patch/149441/ for
example
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -40,8 +40,12 @@
> #include <linux/reciprocal_div.h>
> #include <linux/ratelimit.h>
>
> -/* No hurry in this branch */
> -static void *__load_pointer(const struct sk_buff *skb, int k, unsigned int size)
> +/*
> + * No hurry in this branch
> + *
> + * Exported for the bpf jit load helper.
> + */
Seems good to me, maybe add a strong warning in the comment to say that
function prototype can NOT change without major surgery in ASM files,
since assembler wont catch the prototype change for us.
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
^ permalink raw reply
* [PATCH v2 00/15] mark const init data with __initconst instead of __initdata
From: Uwe Kleine-König @ 2012-03-30 20:03 UTC (permalink / raw)
To: linux-kernel, Andrew Morton
Cc: Andrew Lunn, Christoph Lameter, linux-mips, Tony Lindgren,
Linus Walleij, Nicolas Ferre, Matthew Garrett,
platform-driver-x86, ibm-acpi-devel, Randy Dunlap, linux-mtd,
Sekhar Nori, Daniel Walker, lm-sensors, Klaus Kudielka,
Guenter Roeck, Kevin Hilman, linux-ia64, Kukjin Kim, Russell King,
Samuel Ortiz, Yoshinori Sato, Lennert Buytenhek, Kyungmin Park,
David Brown, Anatolij Gustschin, Jean-Christophe Plagniol-Villard,
Alexey Dobriyan, Joerg Reuter, linux-media, cbe-oss-dev,
Fenghua Yu, Arnd Bergmann, Tony Luck, Lucas De Marchi,
linux-arm-msm, Andreas Koensgen, Henrique de Moraes Holschuh,
Haojian Zhuang, Mauro Carvalho Chehab, Tejun Heo,
linux-samsung-soc, linux-mm, Barry Song, linux-hams, linux-omap,
Andrew Victor, linux-arm-kernel, David Howells,
davinci-linux-open-source, Jean-Paul Roubelat, Eric Miao,
Linus Walleij, linux-ide, linuxppc-dev, Nicolas Pitre,
Ralf Baechle, Tomasz Stanislawski, Bryan Huntsman, Sascha Hauer,
netdev, Jean Delvare, Paul Mackerras, Shawn Guo, David Woodhouse,
David S. Miller
In-Reply-To: <20120329211131.GA31250@pengutronix.de>
Hello,
On Thu, Mar 29, 2012 at 11:11:31PM +0200, Uwe Kleine-König wrote:
> this series fixes a common error to use __initdata to mark const
> variables. Most of the time this works well enough to go unnoticed
> (though I wonder why the linker doesn't warn about that).
> Just try adding something like
>
> int something __initdata;
>
> to one of the patched files and compile to see the error.
>
> While touching these annotations I also corrected the position where it
> was wrong to go between the variable name and the =.
>
> Note this series is not compile tested.
I now dropped the wrong annotations. So two patches became obsolete
(mtd and percpu). Note that I also dropped fixing the position of
__initdata if changing it to __initconst was wrong. (I think if
__initdata is placed before the variable name it doesn't have any
effect.)
I didn't promote the Acks I got because all acked changes changed in v2.
For the details changed in each patch see the changelogs in the
respective patch mails that I follow up to this mail.
Thanks
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v2 10/15] powerpc: mark const init data with __initconst instead of __initdata
From: Uwe Kleine-König @ 2012-03-30 20:05 UTC (permalink / raw)
To: linux-kernel, Andrew Morton
Cc: cbe-oss-dev, Arnd Bergmann, Paul Mackerras, kernel,
Anatolij Gustschin, linuxppc-dev
In-Reply-To: <20120330200358.GV15647@pengutronix.de>
As long as there is no other non-const variable marked __initdata in the
same compilation unit it doesn't hurt. If there were one however
compilation would fail with
error: $variablename causes a section type conflict
because a section containing const variables is marked read only and so
cannot contain non-const variables.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: Josh Boyer <jwboyer@gmail.com>
Cc: Matt Porter <mporter@kernel.crashing.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Anatolij Gustschin <agust@denx.de>
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: cbe-oss-dev@lists.ozlabs.org
---
changes since (implicit) v1:
- drop wrong changes to several files:
- arch/powerpc/platforms/40x/ppc40x_simple.c
- arch/powerpc/platforms/512x/mpc5121_generic.c
- arch/powerpc/platforms/52xx/lite5200.c
- arch/powerpc/platforms/52xx/media5200.c
- arch/powerpc/platforms/52xx/mpc5200_simple.c
- arch/powerpc/platforms/83xx/mpc830x_rdb.c
- arch/powerpc/platforms/83xx/mpc831x_rdb.c
- arch/powerpc/platforms/83xx/mpc837x_rdb.c
- arch/powerpc/platforms/85xx/tqm85xx.c
arch/powerpc/platforms/52xx/mpc52xx_pci.c | 2 +-
arch/powerpc/platforms/cell/qpace_setup.c | 2 +-
arch/powerpc/platforms/cell/setup.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_pci.c b/arch/powerpc/platforms/52xx/mpc52xx_pci.c
index bfb11e0..e2d401a 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_pci.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_pci.c
@@ -93,7 +93,7 @@ struct mpc52xx_pci {
};
/* MPC5200 device tree match tables */
-const struct of_device_id mpc52xx_pci_ids[] __initdata = {
+const struct of_device_id mpc52xx_pci_ids[] __initconst = {
{ .type = "pci", .compatible = "fsl,mpc5200-pci", },
{ .type = "pci", .compatible = "mpc5200-pci", },
{}
diff --git a/arch/powerpc/platforms/cell/qpace_setup.c b/arch/powerpc/platforms/cell/qpace_setup.c
index 7f9b674..6e3409d 100644
--- a/arch/powerpc/platforms/cell/qpace_setup.c
+++ b/arch/powerpc/platforms/cell/qpace_setup.c
@@ -61,7 +61,7 @@ static void qpace_progress(char *s, unsigned short hex)
printk("*** %04x : %s\n", hex, s ? s : "");
}
-static const struct of_device_id qpace_bus_ids[] __initdata = {
+static const struct of_device_id qpace_bus_ids[] __initconst = {
{ .type = "soc", },
{ .compatible = "soc", },
{ .type = "spider", },
diff --git a/arch/powerpc/platforms/cell/setup.c b/arch/powerpc/platforms/cell/setup.c
index fa3e294..4ab0876 100644
--- a/arch/powerpc/platforms/cell/setup.c
+++ b/arch/powerpc/platforms/cell/setup.c
@@ -140,7 +140,7 @@ static int __devinit cell_setup_phb(struct pci_controller *phb)
return 0;
}
-static const struct of_device_id cell_bus_ids[] __initdata = {
+static const struct of_device_id cell_bus_ids[] __initconst = {
{ .type = "soc", },
{ .compatible = "soc", },
{ .type = "spider", },
--
1.7.9.5
^ permalink raw reply related
* Re: kilauea compilation breaks with v3.3 kernel and ELDK 4.2
From: Frank Svendsbøe @ 2012-03-30 22:53 UTC (permalink / raw)
To: Josh Boyer; +Cc: Wolfgang Denk, robert.karl.berger, linuxppc-dev
In-Reply-To: <CA+5PVA4pGhbrM1P8Dbjaxw_1_ZgEweimLCSc1xrw0Rombr_2rg@mail.gmail.com>
On Mon, Mar 26, 2012 at 3:36 PM, Josh Boyer <jwboyer@gmail.com> wrote:
> On Sat, Mar 24, 2012 at 7:53 PM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
>> On Wed, 2012-03-21 at 17:25 +0100, Wolfgang Denk wrote:
>>> > > The problem is that for ppc-linux-gcc (GCC) 4.2.2 (which comes
>>> with the
>>> > > ELDK 4.2) this assembly instruction is not known and the build
>>> breaks.
>>> >
>>> > Sigh. =A0GCC 4.2 is pretty old at this point.
>>>
>>> But still rock-solid ... =A0We use it a lot, especially as reference fo=
r
>>> more recent (and sometimes more broken) versions of GCC.
>>
>> Isn't this a binutils rather than gcc issue ?
>
> Pretty much.
>
Hi Josh Boyer,
just wanted to add that I'm experiencing the same problem that Robert
reported, but on 8xx instead of 4xx. The mpc8xx does not support the
mfdcrx instruction, so maybe it's more to it than just a binutils bug?
Best regards,
Frank
^ permalink raw reply
* [PATCH] powerpc: fix fallout from system.h split up
From: Stephen Rothwell @ 2012-03-31 0:01 UTC (permalink / raw)
To: Linus; +Cc: David Howells, ppc-dev
[-- Attachment #1: Type: text/plain, Size: 1152 bytes --]
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/kernel/fadump.c | 2 ++
arch/powerpc/kernel/kgdb.c | 1 +
2 files changed, 3 insertions(+)
Just a resend of what I sent yesterday - this is what I am using in
linux-next. Linus, please apply.
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index cfe7a38..18bdf74 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -40,6 +40,8 @@
#include <asm/prom.h>
#include <asm/rtas.h>
#include <asm/fadump.h>
+#include <asm/debug.h>
+#include <asm/setup.h>
static struct fw_dump fw_dump;
static struct fadump_mem_struct fdm;
diff --git a/arch/powerpc/kernel/kgdb.c b/arch/powerpc/kernel/kgdb.c
index 76a6e40..782bd0a 100644
--- a/arch/powerpc/kernel/kgdb.c
+++ b/arch/powerpc/kernel/kgdb.c
@@ -24,6 +24,7 @@
#include <asm/current.h>
#include <asm/processor.h>
#include <asm/machdep.h>
+#include <asm/debug.h>
/*
* This table contains the mapping between PowerPC hardware trap types, and
--
1.7.9.5
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* Re: kilauea compilation breaks with v3.3 kernel and ELDK 4.2
From: Benjamin Herrenschmidt @ 2012-03-31 0:03 UTC (permalink / raw)
To: Frank Svendsbøe; +Cc: linuxppc-dev, Wolfgang Denk, robert.karl.berger
In-Reply-To: <CADNf2swF2EVO2u-yPziF2z6HyF6jRBvVsQC2nbY=W2sXJpp2hQ@mail.gmail.com>
On Sat, 2012-03-31 at 00:53 +0200, Frank Svendsbøe wrote:
> Hi Josh Boyer,
>
> just wanted to add that I'm experiencing the same problem that Robert
> reported, but on 8xx instead of 4xx. The mpc8xx does not support the
> mfdcrx instruction, so maybe it's more to it than just a binutils bug?
The kernel shouldn't have tried to build that instruction on 8xx, though
I suppose if it's in arch/powerpc/boot, we are a bit too eager at
building everything including what's not relevant, we might to be a bit
more careful at excluding 4xx stuff on a 8xx kernel.
Can you give us the exact error ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] Bug fix in commit 178db7d3 triggered a bug in the SPI driver for MPC83XX (pdata is NULL).
From: Grant Likely @ 2012-03-30 22:25 UTC (permalink / raw)
To: Kenth Eriksson, spi-devel-general, linuxppc-dev, joakim.tjernlund
Cc: Kenth Eriksson
In-Reply-To: <1333119930-21129-1-git-send-email-kenth.eriksson@transmode.com>
On Fri, 30 Mar 2012 17:05:30 +0200, Kenth Eriksson <kenth.eriksson@transmode.com> wrote:
> After commit 178db7d3 devices are initialized as children of the bus master, not children of the bus masters parent device. The pdata pointer used in fsl_spi_chipselect must updated to reflect the changed initialization.
>
> Signed-off-by: Kenth Eriksson <kenth.eriksson@transmode.com>
Applied; but I have a comments on your commit text.
SHA1 id's are great for looking up commits, but they don't help at all
for casual readers on the mailing list or doing web searches. Please
always include the commit title when referencing an earlier commit. I
had to edit the commit text. Here is what I changed it to:
spi/mpc83xx: fix NULL pdata dereference bug
Commit 178db7d3, "spi: Fix device unregistration when unregistering
the bus master", changed device initialization to be children of the
bus master, not children of the bus masters parent device. The pdata
pointer used in fsl_spi_chipselect must updated to reflect the changed
initialization.
g.
> ---
> drivers/spi/spi-fsl-spi.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/spi/spi-fsl-spi.c b/drivers/spi/spi-fsl-spi.c
> index 7d6ca68..dc747a0 100644
> --- a/drivers/spi/spi-fsl-spi.c
> +++ b/drivers/spi/spi-fsl-spi.c
> @@ -139,10 +139,12 @@ static void fsl_spi_change_mode(struct spi_device *spi)
> static void fsl_spi_chipselect(struct spi_device *spi, int value)
> {
> struct mpc8xxx_spi *mpc8xxx_spi = spi_master_get_devdata(spi->master);
> - struct fsl_spi_platform_data *pdata = spi->dev.parent->platform_data;
> + struct fsl_spi_platform_data *pdata;
> bool pol = spi->mode & SPI_CS_HIGH;
> struct spi_mpc8xxx_cs *cs = spi->controller_state;
>
> + pdata = spi->dev.parent->parent->platform_data;
> +
> if (value == BITBANG_CS_INACTIVE) {
> if (pdata->cs_control)
> pdata->cs_control(spi, !pol);
> --
> 1.7.3.4
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> spi-devel-general mailing list
> spi-devel-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/spi-devel-general
--
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies,Ltd.
^ permalink raw reply
* teach i2c-mpc to selectively ignore !RXAK errors
From: Anthony Foiani @ 2012-03-31 9:19 UTC (permalink / raw)
To: linuxppc-dev
On the project I'm working on, the hardware engineers put an I2C
device behind a unidirectional level translator. When I tried to
write to it, I was getting EIO due to the lack of receiver ack.
This is my hack to support this situation, based off 3.0.6 with a few
minor additions (none of which impact the I2C bits, SFAICT).
There are really two distinct changes here:
1. Change mpc_read and mpc_write to take a generic "flags" argument,
instead of just passing the message index; and
2. In the very specific case of performing a write when the user has
specified I2C_M_NO_RD_ACK on a message, do not error out on !RXAK
condition.
My apologies for not breaking it down, but I don't have the bandwidth
to respin and track this change. I'm mostly posting it so that other
people can find it if they run into the same issue.
The use of I2C_M_NO_RD_ACK is a bit obscure, but it's barely used in
the kernel, and it makes a certain amount of sense in this context.
Thanks to everyone that's contributed to the PPC Linux stack; it's
made this project (and my current livelihood!) possible.
Best Regards,
Anthony Foiani
-----------------------------------------------------------------------
>From a529752a703bcbb4a751e2e8fef721a65c702c6f Mon Sep 17 00:00:00 2001
From: Anthony Foiani <anthony.foiani@gmail.com>
Date: Wed, 28 Mar 2012 20:51:53 -0600
Subject: [PATCH] Selectively ignore missing RXAK.
Overload the I2C_M_NO_RD_ACK flag to continue with writes even when
the receiver has not acknowledged. This was useful when talking to a
part that was electrically isolated such that it could not drive the
bus lines back to the CPU.
Signed-Off-By: Anthony Foiani <anthony.foiani@gmail.com>
---
drivers/i2c/busses/i2c-mpc.c | 46 ++++++++++++++++++++++++-----------------
1 files changed, 27 insertions(+), 19 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index 107397a..961a0e1 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -48,6 +48,8 @@
#define CCR_TXAK 0x08
#define CCR_RSTA 0x04
+#define CCR_MASK 0xff
+
#define CSR_MCF 0x80
#define CSR_MAAS 0x40
#define CSR_MBB 0x20
@@ -116,7 +118,7 @@ static void mpc_i2c_fixup(struct mpc_i2c *i2c)
}
}
-static int i2c_wait(struct mpc_i2c *i2c, unsigned timeout, int writing)
+static int i2c_wait(struct mpc_i2c *i2c, unsigned timeout, int writing, u32 flags)
{
unsigned long orig_jiffies = jiffies;
u32 x;
@@ -163,10 +165,13 @@ static int i2c_wait(struct mpc_i2c *i2c, unsigned timeout, int writing)
}
if (writing && (x & CSR_RXAK)) {
- dev_dbg(i2c->dev, "No RXAK\n");
- /* generate stop */
- writeccr(i2c, CCR_MEN);
- return -EIO;
+ if (!(flags & I2C_M_NO_RD_ACK)) {
+ dev_dbg(i2c->dev, "No RXAK\n");
+ /* generate stop */
+ writeccr(i2c, CCR_MEN);
+ return -EIO;
+ }
+ dev_dbg(i2c->dev, "suppressed !RXAK\n");
}
return 0;
}
@@ -426,18 +431,18 @@ static void mpc_i2c_stop(struct mpc_i2c *i2c)
}
static int mpc_write(struct mpc_i2c *i2c, int target,
- const u8 *data, int length, int restart)
+ const u8 *data, int length, u32 flags)
{
int i, result;
unsigned timeout = i2c->adap.timeout;
- u32 flags = restart ? CCR_RSTA : 0;
/* Start as master */
- writeccr(i2c, CCR_MIEN | CCR_MEN | CCR_MSTA | CCR_MTX | flags);
+ writeccr(i2c, CCR_MIEN | CCR_MEN | CCR_MSTA |
+ CCR_MTX | (flags & CCR_MASK));
/* Write target byte */
writeb((target << 1), i2c->base + MPC_I2C_DR);
- result = i2c_wait(i2c, timeout, 1);
+ result = i2c_wait(i2c, timeout, 1, flags);
if (result < 0)
return result;
@@ -445,7 +450,7 @@ static int mpc_write(struct mpc_i2c *i2c, int target,
/* Write data byte */
writeb(data[i], i2c->base + MPC_I2C_DR);
- result = i2c_wait(i2c, timeout, 1);
+ result = i2c_wait(i2c, timeout, 1, flags);
if (result < 0)
return result;
}
@@ -454,18 +459,18 @@ static int mpc_write(struct mpc_i2c *i2c, int target,
}
static int mpc_read(struct mpc_i2c *i2c, int target,
- u8 *data, int length, int restart)
+ u8 *data, int length, u32 flags)
{
unsigned timeout = i2c->adap.timeout;
int i, result;
- u32 flags = restart ? CCR_RSTA : 0;
/* Switch to read - restart */
- writeccr(i2c, CCR_MIEN | CCR_MEN | CCR_MSTA | CCR_MTX | flags);
+ writeccr(i2c, CCR_MIEN | CCR_MEN | CCR_MSTA |
+ CCR_MTX | (flags & CCR_MASK));
/* Write target address byte - this time with the read flag set */
writeb((target << 1) | 1, i2c->base + MPC_I2C_DR);
- result = i2c_wait(i2c, timeout, 1);
+ result = i2c_wait(i2c, timeout, 1, flags);
if (result < 0)
return result;
@@ -479,7 +484,7 @@ static int mpc_read(struct mpc_i2c *i2c, int target,
}
for (i = 0; i < length; i++) {
- result = i2c_wait(i2c, timeout, 0);
+ result = i2c_wait(i2c, timeout, 0, flags);
if (result < 0)
return result;
@@ -502,6 +507,7 @@ static int mpc_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
int ret = 0;
unsigned long orig_jiffies = jiffies;
struct mpc_i2c *i2c = i2c_get_adapdata(adap);
+ u32 restart;
mpc_i2c_start(i2c);
@@ -526,6 +532,7 @@ static int mpc_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
schedule();
}
+ restart = 0;
for (i = 0; ret >= 0 && i < num; i++) {
pmsg = &msgs[i];
dev_dbg(i2c->dev,
@@ -533,11 +540,12 @@ static int mpc_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
pmsg->flags & I2C_M_RD ? "read" : "write",
pmsg->len, pmsg->addr, i + 1, num);
if (pmsg->flags & I2C_M_RD)
- ret =
- mpc_read(i2c, pmsg->addr, pmsg->buf, pmsg->len, i);
+ ret = mpc_read(i2c, pmsg->addr, pmsg->buf, pmsg->len,
+ restart | (pmsg->flags & ~CCR_MASK));
else
- ret =
- mpc_write(i2c, pmsg->addr, pmsg->buf, pmsg->len, i);
+ ret = mpc_write(i2c, pmsg->addr, pmsg->buf, pmsg->len,
+ restart | (pmsg->flags & ~CCR_MASK));
+ restart = CCR_RSTA;
}
mpc_i2c_stop(i2c);
return (ret < 0) ? ret : num;
--
1.7.7.6
^ permalink raw reply related
* [PATCH 0/19 v2] mmu: arch/mm: Port OOM changes to arch page fault handlers.
From: Kautuk Consul @ 2012-03-31 11:58 UTC (permalink / raw)
To: linux-alpha, linuxppc-dev, linux, linux-am33-list,
microblaze-uclinux, linux-m68k, linux-m32r-ja, linux-ia64,
linux-hexagon, linux-cris-kernel, linux-sh, linux-parisc,
linux-mm, linux-arch
Cc: linux-kernel
In-Reply-To: <CAFPAmTQs9dOpQTaXU=6Or66YU+my_CnPw33TE4h++YArBNa38g@mail.gmail.com>
Commit d065bd810b6deb67d4897a14bfe21f8eb526ba99
(mm: retry page fault when blocking on disk transfer) and
commit 37b23e0525d393d48a7d59f870b3bc061a30ccdb
(x86,mm: make pagefault killable)
The above commits introduced changes into the x86 pagefault handler
for making the page fault handler retryable as well as killable.
These changes reduce the mmap_sem hold time, which is crucial
during OOM killer invocation.
I was facing hang and livelock problems on my ARM and MIPS boards when
I invoked OOM by running the stress_32k.c test-case attached to this email.
Since both the ARM and MIPS porting changes were accepted, me and my
co-worker decided to take the initiative to port these changes to all other
MMU based architectures.
This is v2 of this patch set as there were some problems with the v1 of this
patchset:
- Whitespace issues as reported by David Miller and Joe Perches
- In 2 of the patches, the write(or equivalent) local variable has
been removed from the
page fault handler because it is not really needed anymore with the
advent of the "flags"
local variable. Thanks to Geert Uytterhoeven for that.
- The powerpc patch for this has been removed as this has already been
done by someone
else for powerpc.
At the moment, 8 of these patches have Acked these patches as valid.
I have included their ACKed-By headers for them in their respective
arch patches.
And thanks to Guan Xuetao for actually testing this out on unicore32.
Rest of the arch owners: Please review these patches.
Signed-off-by: Mohd. Faris <mohdfarisq2010@gmail.com>
Signed-off-by: Kautuk Consul <consul.kautuk@gmail.com>
---
^ permalink raw reply
* Re: [PATCH 0/19 v2] mmu: arch/mm: Port OOM changes to arch page fault handlers.
From: Kautuk Consul @ 2012-03-31 12:15 UTC (permalink / raw)
To: linux-alpha, linuxppc-dev, linux, linux-am33-list,
microblaze-uclinux, linux-m68k, linux-m32r-ja, linux-ia64,
linux-hexagon, linux-cris-kernel, linux-sh, linux-parisc,
linux-mm, linux-arch
Cc: linux-kernel
In-Reply-To: <CAFPAmTT19hFymnFftLkV1jQjYmJgyk3y4b-kTXO3VP1YCR-_fQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 110 bytes --]
Ugh, sorry I forgot to attach the stress_32k.c test-case to this email.
Please find it attached to this one.
[-- Attachment #2: stress_32k.c --]
[-- Type: text/x-csrc, Size: 3897 bytes --]
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <pthread.h>
#include <unistd.h>
#define ALLOC_BYTE 512*1024
#define COUNT 50
void *alloc_function_one( void *ptr );
void *alloc_function_two( void *ptr );
void *alloc_function_three( void *ptr );
void *alloc_function_four( void *ptr );
void *alloc_function_five( void *ptr );
void *enable_function( void *ptr );
int main(int argc, char *argv[])
{
pthread_t thread1, thread2, thread3, thread4, thread5;
char *message1 = "Thread 1";
char *message2 = "Thread 2";
char *message3 = "Thread 3";
char *message4 = "Thread 4";
char *message5 = "Thread 5";
int iret1 = -1;
int iret2 = -1;
int iret3 = -1;
int iret4 = -1;
int iret5 = -1;
fork();
iret1 = pthread_create( &thread1, NULL, alloc_function_one, (void*) message1);
iret2 = pthread_create( &thread2, NULL, alloc_function_two, (void*) message2);
iret2 = pthread_create( &thread3, NULL, alloc_function_three, (void*) message2);
iret2 = pthread_create( &thread4, NULL, alloc_function_four, (void*) message2);
iret2 = pthread_create( &thread5, NULL, alloc_function_five, (void*) message2);
pthread_join( thread1, NULL);
pthread_join( thread2, NULL);
pthread_join( thread3, NULL);
pthread_join( thread4, NULL);
pthread_join( thread5, NULL);
printf("Thread 1 returns: %d\n",iret1);
printf("Thread 2 returns: %d\n",iret2);
printf("Thread 3 returns: %d\n",iret3);
printf("Thread 4 returns: %d\n",iret4);
printf("Thread 5 returns: %d\n",iret5);
exit(0);
}
void *alloc_function_two( void *ptr )
{
char *message;
message = (char *) ptr;
void *myblock[COUNT];
int i= 0,j=0;
int freed=0;
printf("message_alloc \n");
while(1)
{
memset(myblock,0,sizeof(myblock));
printf("message_alloc %s \n",message);
for(i=0;i< COUNT ;i++)
{
myblock[i] = (void *) malloc(ALLOC_BYTE);
memset(myblock[i],1, ALLOC_BYTE);
}
}
}
void *alloc_function_one( void *ptr )
{
char *message;
message = (char *) ptr;
void *myblock[COUNT];
int i= 0,j=0;
int freed=0;
printf("message_alloc \n");
while(1)
{
memset(myblock,0,sizeof(myblock));
printf("message_alloc %s \n",message);
for(i=0;i< COUNT ;i++)
{
myblock[i] = (void *) malloc(ALLOC_BYTE);
memset(myblock[i],1, ALLOC_BYTE);
}
}
}
void *alloc_function_three( void *ptr )
{
char *message;
message = (char *) ptr;
void *myblock[COUNT];
int i= 0,j=0;
int freed=0;
printf("message_alloc \n");
while(1)
{
memset(myblock,0,sizeof(myblock));
printf("message_alloc %s \n",message);
for(i=0;i< COUNT ;i++)
{
myblock[i] = (void *) malloc(ALLOC_BYTE);
memset(myblock[i],1, ALLOC_BYTE);
}
}
}
void *alloc_function_four( void *ptr )
{
char *message;
message = (char *) ptr;
void *myblock[COUNT];
int i= 0,j=0;
int freed=0;
printf("message_alloc \n");
while(1)
{
memset(myblock,0,sizeof(myblock));
printf("message_alloc %s \n",message);
for(i=0;i< COUNT ;i++)
{
myblock[i] = (void *) malloc(ALLOC_BYTE);
memset(myblock[i],1, ALLOC_BYTE);
}
}
}
void *alloc_function_five( void *ptr )
{
char *message;
message = (char *) ptr;
void *myblock[COUNT];
int i= 0,j=0;
int freed=0;
printf("message_alloc \n");
while(1)
{
memset(myblock,0,sizeof(myblock));
printf("message_alloc %s \n",message);
for(i=0;i< COUNT ;i++)
{
myblock[i] = (void *) malloc(ALLOC_BYTE);
memset(myblock[i],1, ALLOC_BYTE);
}
}
}
^ permalink raw reply
* Re: powerpc/85xx: p2020rdb - move the NAND address.
From: Kumar Gala @ 2012-03-31 14:48 UTC (permalink / raw)
To: Sebastian Andrzej Siewior; +Cc: Bryan Hundven, linuxppc-dev
In-Reply-To: <4F75BD6B.30609@linutronix.de>
On Mar 30, 2012, at 9:04 AM, Sebastian Andrzej Siewior wrote:
> On 03/29/2012 03:10 PM, Kumar Gala wrote:
>
>>> - include/configs/P1_P2_RDB.h
>>>
>>> #ifndef CONFIG_NAND_SPL
>>> #define CONFIG_SYS_NAND_BASE 0xffa00000
>>> #ifdef CONFIG_PHYS_64BIT
>>> #define CONFIG_SYS_NAND_BASE_PHYS 0xfffa00000ull
>>> #else
>>> #define CONFIG_SYS_NAND_BASE_PHYS CONFIG_SYS_NAND_BASE
>>> #endif
>>> #else
>>> #define CONFIG_SYS_NAND_BASE 0xfff00000
>>> #ifdef CONFIG_PHYS_64BIT
>>> #define CONFIG_SYS_NAND_BASE_PHYS 0xffff00000ull
>>> #else
>>> #define CONFIG_SYS_NAND_BASE_PHYS CONFIG_SYS_NAND_BASE
>>> #endif
>>> #endif
>>>
>>> - include/configs/p1_p2_rdb_pc.h
>>>
>>> #ifdef CONFIG_NAND_FSL_ELBC
>>> #define CONFIG_SYS_NAND_BASE 0xff800000
>>> #ifdef CONFIG_PHYS_64BIT
>>> #define CONFIG_SYS_NAND_BASE_PHYS 0xfff800000ull
>>> #else
>>> #define CONFIG_SYS_NAND_BASE_PHYS CONFIG_SYS_NAND_BASE
>>> #endif
>>>
>>
>> There are two (well 3 since rdb-pc has both 32b& 36b) in the tree now:
>>
>> arch/powerpc/boot/dts/p2020rdb.dts
>> arch/powerpc/boot/dts/p2020rdb-pc_32b.dts
>> arch/powerpc/boot/dts/p2020rdb-pc_36b.dts
>
> Okay. So I assume that one has the proper NAND address and my patch
> should be reverted then. Do want a patch from me for that?
Yes, please do.
>>> Since both system have the same SoC and the NAND_SPL is always linked
>>> against 0xfff00000 I don't see anything wrong to relocate the NAND CS
>>> later to 0xff800000 (or to 0xffa00000) and having it consistent among
>>> both configs.
>
> what about this thing? Should leave it as it or move to the same
> location? Since I have no HW *I* would prefer not to touch it :)
Hmm, that implies a u-boot change, right?
- k
^ permalink raw reply
* [PATCH RFC] Simplify the Linux kernel by reducing its state space
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
* Re: [PATCH RFC] Simplify the Linux kernel by reducing its state space
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
In-Reply-To: <20120331163321.GA15809@linux.vnet.ibm.com>
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
* Re: [PATCH RFC] Simplify the Linux kernel by reducing its state space
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
In-Reply-To: <CAMuHMdWTB+_AtqM6JixY=Oo_zmzX_dNxnivpARBYSbPJzp4t6A@mail.gmail.com>
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
* Re: [PATCH RFC] Simplify the Linux kernel by reducing its state space
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
In-Reply-To: <20120331163321.GA15809@linux.vnet.ibm.com>
[-- 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
* Re: [PATCH RFC] Simplify the Linux kernel by reducing its state space
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
In-Reply-To: <20120331163321.GA15809@linux.vnet.ibm.com>
[-- 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
* Re: [PATCH RFC] Simplify the Linux kernel by reducing its state space
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
In-Reply-To: <CAHrUA35Bz68DtP-Znr=-+U+6P9CONXzN=9JdMXRfRwmVV9fy=Q@mail.gmail.com>
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
* Re: [PATCH RFC] Simplify the Linux kernel by reducing its state space
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
In-Reply-To: <20120331201500.GA27640@linas.org>
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
* Re: [PATCH RFC] Simplify the Linux kernel by reducing its state space
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
In-Reply-To: <4F77681E.5010608@xenotime.net>
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
* Re: [PATCH RFC] Simplify the Linux kernel by reducing its state space
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
In-Reply-To: <20120331163321.GA15809@linux.vnet.ibm.com>
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
* Re: [PATCH RFC] Simplify the Linux kernel by reducing its state space
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
In-Reply-To: <1333227608.2325.4054.camel@edumazet-glaptop>
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
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox