All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	uclinux-dist-devel@blackfin.uclinux.org,
	linux-hexagon@vger.kernel.org, linux-ia64@vger.kernel.org,
	linux-m32r@ml.linux-m32r.org, linux-m32r-ja@ml.linux-m32r.org,
	linux-mips@linux-mips.org, linux-am33-list@redhat.com,
	linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-s390@vger.kernel.org, linux-sh@vger.kernel.org,
	sparclinux@vger.kernel.org, tglx@linutronix.de,
	dhowells@redhat.com, jejb@parisc-linux.org, linux390@de.ibm.com,
	x86@kernel.org, cmetcalf@tilera.com
Subject: Re: [PATCH RFC] Simplify the Linux kernel by reducing its state	space
Date: Sat, 31 Mar 2012 18:22:12 -0700	[thread overview]
Message-ID: <20120401012212.GP2450@linux.vnet.ibm.com> (raw)
In-Reply-To: <20120331223200.GA32482@n2100.arm.linux.org.uk>

On Sat, Mar 31, 2012 at 11:32:00PM +0100, Russell King - ARM Linux wrote:
> On Sun, Apr 01, 2012 at 12:33:21AM +0800, Paul E. McKenney wrote:
> > Although there have been numerous complaints about the complexity of
> > parallel programming (especially over the past 5-10 years), the plain
> > truth is that the incremental complexity of parallel programming over
> > that of sequential programming is not as large as is commonly believed.
> > Despite that you might have heard, the mind-numbing complexity of modern
> > computer systems is not due so much to there being multiple CPUs, but
> > rather to there being any CPUs at all.  In short, for the ultimate in
> > computer-system simplicity, the optimal choice is NR_CPUS=0.
> > 
> > This commit therefore limits kernel builds to zero CPUs.  This change
> > has the beneficial side effect of rendering all kernel bugs harmless.
> > Furthermore, this commit enables additional beneficial changes, for
> > example, the removal of those parts of the kernel that are not needed
> > when there are zero CPUs.
> > 
> > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
> 
> Great work, but I don't think you've gone far enough with this.
> 
> What would really help is if you could consolidate all these NR_CPUS
> definitions into one place so we don't have essentially the same thing
> scattered across all these architectures.  We're already doing this on
> ARM across our platforms, and its about time such an approach was taken
> across the entire kernel tree.
> 
> It looks like the MIPS solution would be the best one to pick.
> Could you rework your patch to do this please?
> 
> While you're at it, you might like to consider that having zero CPUs
> makes all this architecture support redundant, so maybe you've missed
> a trick there - according to my count, we could get rid of almost 3
> million lines of code from arch.  We could replace all that with a
> single standard implementation.
> 
> Bah, maybe I shouldn't have pushed that bpf_jit code for ARM after all...

;-) ;-) ;-)

							Thanx, Paul


WARNING: multiple messages have this Message-ID (diff)
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH RFC] Simplify the Linux kernel by reducing its state	space
Date: Sun, 01 Apr 2012 01:22:12 +0000	[thread overview]
Message-ID: <20120401012212.GP2450@linux.vnet.ibm.com> (raw)
In-Reply-To: <20120331223200.GA32482@n2100.arm.linux.org.uk>

On Sat, Mar 31, 2012 at 11:32:00PM +0100, Russell King - ARM Linux wrote:
> On Sun, Apr 01, 2012 at 12:33:21AM +0800, Paul E. McKenney wrote:
> > Although there have been numerous complaints about the complexity of
> > parallel programming (especially over the past 5-10 years), the plain
> > truth is that the incremental complexity of parallel programming over
> > that of sequential programming is not as large as is commonly believed.
> > Despite that you might have heard, the mind-numbing complexity of modern
> > computer systems is not due so much to there being multiple CPUs, but
> > rather to there being any CPUs at all.  In short, for the ultimate in
> > computer-system simplicity, the optimal choice is NR_CPUS=0.
> > 
> > This commit therefore limits kernel builds to zero CPUs.  This change
> > has the beneficial side effect of rendering all kernel bugs harmless.
> > Furthermore, this commit enables additional beneficial changes, for
> > example, the removal of those parts of the kernel that are not needed
> > when there are zero CPUs.
> > 
> > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
> 
> Great work, but I don't think you've gone far enough with this.
> 
> What would really help is if you could consolidate all these NR_CPUS
> definitions into one place so we don't have essentially the same thing
> scattered across all these architectures.  We're already doing this on
> ARM across our platforms, and its about time such an approach was taken
> across the entire kernel tree.
> 
> It looks like the MIPS solution would be the best one to pick.
> Could you rework your patch to do this please?
> 
> While you're at it, you might like to consider that having zero CPUs
> makes all this architecture support redundant, so maybe you've missed
> a trick there - according to my count, we could get rid of almost 3
> million lines of code from arch.  We could replace all that with a
> single standard implementation.
> 
> Bah, maybe I shouldn't have pushed that bpf_jit code for ARM after all...

;-) ;-) ;-)

							Thanx, Paul


WARNING: multiple messages have this Message-ID (diff)
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	uclinux-dist-devel@blackfin.uclinux.org,
	linux-hexagon@vger.kernel.org, linux-ia64@vger.kernel.org,
	linux-m32r@ml.linux-m32r.org, linux-m32r-ja@ml.linux-m32r.org,
	linux-mips@linux-mips.org, linux-am33-list@redhat.com,
	linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-s390@vger.kernel.org, linux-sh@vger.kernel.org,
	sparclinux@vger.kernel.org, tglx@linutronix.de,
	dhowells@redhat.com, jejb@parisc-linux.org, linux390@de.ibm.com,
	x86@kernel.org, cmetcalf@tilera.com
Subject: Re: [PATCH RFC] Simplify the Linux kernel by reducing its state        space
Date: Sat, 31 Mar 2012 18:22:12 -0700	[thread overview]
Message-ID: <20120401012212.GP2450@linux.vnet.ibm.com> (raw)
In-Reply-To: <20120331223200.GA32482@n2100.arm.linux.org.uk>

On Sat, Mar 31, 2012 at 11:32:00PM +0100, Russell King - ARM Linux wrote:
> On Sun, Apr 01, 2012 at 12:33:21AM +0800, Paul E. McKenney wrote:
> > Although there have been numerous complaints about the complexity of
> > parallel programming (especially over the past 5-10 years), the plain
> > truth is that the incremental complexity of parallel programming over
> > that of sequential programming is not as large as is commonly believed.
> > Despite that you might have heard, the mind-numbing complexity of modern
> > computer systems is not due so much to there being multiple CPUs, but
> > rather to there being any CPUs at all.  In short, for the ultimate in
> > computer-system simplicity, the optimal choice is NR_CPUS=0.
> > 
> > This commit therefore limits kernel builds to zero CPUs.  This change
> > has the beneficial side effect of rendering all kernel bugs harmless.
> > Furthermore, this commit enables additional beneficial changes, for
> > example, the removal of those parts of the kernel that are not needed
> > when there are zero CPUs.
> > 
> > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
> 
> Great work, but I don't think you've gone far enough with this.
> 
> What would really help is if you could consolidate all these NR_CPUS
> definitions into one place so we don't have essentially the same thing
> scattered across all these architectures.  We're already doing this on
> ARM across our platforms, and its about time such an approach was taken
> across the entire kernel tree.
> 
> It looks like the MIPS solution would be the best one to pick.
> Could you rework your patch to do this please?
> 
> While you're at it, you might like to consider that having zero CPUs
> makes all this architecture support redundant, so maybe you've missed
> a trick there - according to my count, we could get rid of almost 3
> million lines of code from arch.  We could replace all that with a
> single standard implementation.
> 
> Bah, maybe I shouldn't have pushed that bpf_jit code for ARM after all...

;-) ;-) ;-)

							Thanx, Paul

WARNING: multiple messages have this Message-ID (diff)
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: linux-m32r-ja@ml.linux-m32r.org, linux-mips@linux-mips.org,
	linux-m32r@ml.linux-m32r.org, linux-ia64@vger.kernel.org,
	linux-parisc@vger.kernel.org, linux-s390@vger.kernel.org,
	linux-hexagon@vger.kernel.org, linux-sh@vger.kernel.org,
	linux-kernel@vger.kernel.org, x86@kernel.org,
	jejb@parisc-linux.org, dhowells@redhat.com, linux390@de.ibm.com,
	linux-am33-list@redhat.com, cmetcalf@tilera.com,
	linux-alpha@vger.kernel.org, sparclinux@vger.kernel.org,
	uclinux-dist-devel@blackfin.uclinux.org, tglx@linutronix.de,
	linuxppc-dev@lists.ozlabs.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH RFC] Simplify the Linux kernel by reducing its state	space
Date: Sat, 31 Mar 2012 18:22:12 -0700	[thread overview]
Message-ID: <20120401012212.GP2450@linux.vnet.ibm.com> (raw)
In-Reply-To: <20120331223200.GA32482@n2100.arm.linux.org.uk>

On Sat, Mar 31, 2012 at 11:32:00PM +0100, Russell King - ARM Linux wrote:
> On Sun, Apr 01, 2012 at 12:33:21AM +0800, Paul E. McKenney wrote:
> > Although there have been numerous complaints about the complexity of
> > parallel programming (especially over the past 5-10 years), the plain
> > truth is that the incremental complexity of parallel programming over
> > that of sequential programming is not as large as is commonly believed.
> > Despite that you might have heard, the mind-numbing complexity of modern
> > computer systems is not due so much to there being multiple CPUs, but
> > rather to there being any CPUs at all.  In short, for the ultimate in
> > computer-system simplicity, the optimal choice is NR_CPUS=0.
> > 
> > This commit therefore limits kernel builds to zero CPUs.  This change
> > has the beneficial side effect of rendering all kernel bugs harmless.
> > Furthermore, this commit enables additional beneficial changes, for
> > example, the removal of those parts of the kernel that are not needed
> > when there are zero CPUs.
> > 
> > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
> 
> Great work, but I don't think you've gone far enough with this.
> 
> What would really help is if you could consolidate all these NR_CPUS
> definitions into one place so we don't have essentially the same thing
> scattered across all these architectures.  We're already doing this on
> ARM across our platforms, and its about time such an approach was taken
> across the entire kernel tree.
> 
> It looks like the MIPS solution would be the best one to pick.
> Could you rework your patch to do this please?
> 
> While you're at it, you might like to consider that having zero CPUs
> makes all this architecture support redundant, so maybe you've missed
> a trick there - according to my count, we could get rid of almost 3
> million lines of code from arch.  We could replace all that with a
> single standard implementation.
> 
> Bah, maybe I shouldn't have pushed that bpf_jit code for ARM after all...

;-) ;-) ;-)

							Thanx, Paul

WARNING: multiple messages have this Message-ID (diff)
From: paulmck@linux.vnet.ibm.com (Paul E. McKenney)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH RFC] Simplify the Linux kernel by reducing its state	space
Date: Sat, 31 Mar 2012 18:22:12 -0700	[thread overview]
Message-ID: <20120401012212.GP2450@linux.vnet.ibm.com> (raw)
In-Reply-To: <20120331223200.GA32482@n2100.arm.linux.org.uk>

On Sat, Mar 31, 2012 at 11:32:00PM +0100, Russell King - ARM Linux wrote:
> On Sun, Apr 01, 2012 at 12:33:21AM +0800, Paul E. McKenney wrote:
> > Although there have been numerous complaints about the complexity of
> > parallel programming (especially over the past 5-10 years), the plain
> > truth is that the incremental complexity of parallel programming over
> > that of sequential programming is not as large as is commonly believed.
> > Despite that you might have heard, the mind-numbing complexity of modern
> > computer systems is not due so much to there being multiple CPUs, but
> > rather to there being any CPUs at all.  In short, for the ultimate in
> > computer-system simplicity, the optimal choice is NR_CPUS=0.
> > 
> > This commit therefore limits kernel builds to zero CPUs.  This change
> > has the beneficial side effect of rendering all kernel bugs harmless.
> > Furthermore, this commit enables additional beneficial changes, for
> > example, the removal of those parts of the kernel that are not needed
> > when there are zero CPUs.
> > 
> > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
> 
> Great work, but I don't think you've gone far enough with this.
> 
> What would really help is if you could consolidate all these NR_CPUS
> definitions into one place so we don't have essentially the same thing
> scattered across all these architectures.  We're already doing this on
> ARM across our platforms, and its about time such an approach was taken
> across the entire kernel tree.
> 
> It looks like the MIPS solution would be the best one to pick.
> Could you rework your patch to do this please?
> 
> While you're at it, you might like to consider that having zero CPUs
> makes all this architecture support redundant, so maybe you've missed
> a trick there - according to my count, we could get rid of almost 3
> million lines of code from arch.  We could replace all that with a
> single standard implementation.
> 
> Bah, maybe I shouldn't have pushed that bpf_jit code for ARM after all...

;-) ;-) ;-)

							Thanx, Paul

  reply	other threads:[~2012-04-01  1:22 UTC|newest]

Thread overview: 77+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-31 16:33 [PATCH RFC] Simplify the Linux kernel by reducing its state space Paul E. McKenney
2012-03-31 16:33 ` Paul E. McKenney
2012-03-31 16:33 ` Paul E. McKenney
2012-03-31 16:33 ` Paul E. McKenney
2012-03-31 16:40 ` Geert Uytterhoeven
2012-03-31 16:40   ` Geert Uytterhoeven
2012-03-31 16:40   ` Geert Uytterhoeven
2012-03-31 16:40   ` Geert Uytterhoeven
2012-03-31 16:40   ` Geert Uytterhoeven
2012-03-31 16:40   ` Geert Uytterhoeven
2012-03-31 16:40   ` Geert Uytterhoeven
2012-03-31 16:54   ` Paul E. McKenney
2012-03-31 16:54     ` Paul E. McKenney
2012-03-31 16:54     ` Paul E. McKenney
2012-03-31 16:54     ` Paul E. McKenney
2012-03-31 16:54     ` Paul E. McKenney
2012-03-31 16:54     ` Paul E. McKenney
2012-03-31 16:54   ` Paul E. McKenney
2012-03-31 16:40 ` Geert Uytterhoeven
2012-03-31 19:57 ` Linas Vepstas
2012-03-31 19:57   ` Linas Vepstas
2012-03-31 20:14   ` Paul E. McKenney
2012-03-31 20:14     ` Paul E. McKenney
2012-03-31 20:14     ` Paul E. McKenney
2012-03-31 20:14     ` Paul E. McKenney
2012-03-31 20:15 ` Linas Vepstas
2012-03-31 20:15   ` Linas Vepstas
2012-03-31 20:15   ` Linas Vepstas
2012-03-31 20:15   ` Linas Vepstas
2012-03-31 20:25   ` Randy Dunlap
2012-03-31 20:25     ` Randy Dunlap
2012-03-31 20:25     ` Randy Dunlap
2012-03-31 20:25     ` Randy Dunlap
2012-03-31 20:43     ` Paul E. McKenney
2012-03-31 20:43       ` Paul E. McKenney
2012-03-31 20:43       ` Paul E. McKenney
2012-03-31 20:43       ` Paul E. McKenney
2012-03-31 21:00 ` Eric Dumazet
2012-03-31 21:00   ` Eric Dumazet
2012-03-31 21:00   ` Eric Dumazet
2012-03-31 21:00   ` Eric Dumazet
2012-03-31 21:21   ` Paul E. McKenney
2012-03-31 21:21     ` Paul E. McKenney
2012-03-31 21:21     ` Paul E. McKenney
2012-03-31 21:21     ` Paul E. McKenney
2012-03-31 22:19     ` Lorenz Kolb
2012-03-31 22:19       ` Lorenz Kolb
2012-03-31 22:19       ` Lorenz Kolb
2012-03-31 22:19       ` Lorenz Kolb
2012-03-31 22:34       ` Paul E. McKenney
2012-03-31 22:34         ` Paul E. McKenney
2012-03-31 22:34         ` Paul E. McKenney
2012-03-31 22:34         ` Paul E. McKenney
2012-03-31 22:32 ` Russell King - ARM Linux
2012-03-31 22:32   ` Russell King - ARM Linux
2012-03-31 22:32   ` Russell King - ARM Linux
2012-03-31 22:32   ` Russell King - ARM Linux
2012-04-01  1:22   ` Paul E. McKenney [this message]
2012-04-01  1:22     ` Paul E. McKenney
2012-04-01  1:22     ` Paul E. McKenney
2012-04-01  1:22     ` Paul E. McKenney
2012-04-01  1:22     ` Paul E. McKenney
2012-04-01 17:34   ` Thomas Gleixner
2012-04-01 17:34     ` Thomas Gleixner
2012-04-01 17:34     ` Thomas Gleixner
2012-04-01 17:34     ` Thomas Gleixner
2012-04-01 18:12     ` Paul E. McKenney
2012-04-01 18:12       ` Paul E. McKenney
2012-04-01 18:12       ` Paul E. McKenney
2012-04-01 18:12       ` Paul E. McKenney
2012-04-01 10:04 ` Borislav Petkov
2012-04-01 10:04   ` Borislav Petkov
2012-04-01 10:04   ` Borislav Petkov
2012-04-01 10:04   ` Borislav Petkov
2012-04-01 18:11   ` Paul E. McKenney
2012-04-01 18:11     ` Paul E. McKenney
2012-04-01 18:11     ` Paul E. McKenney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120401012212.GP2450@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=cmetcalf@tilera.com \
    --cc=dhowells@redhat.com \
    --cc=jejb@parisc-linux.org \
    --cc=linux-alpha@vger.kernel.org \
    --cc=linux-am33-list@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-hexagon@vger.kernel.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m32r-ja@ml.linux-m32r.org \
    --cc=linux-m32r@ml.linux-m32r.org \
    --cc=linux-mips@linux-mips.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=linux390@de.ibm.com \
    --cc=linux@arm.linux.org.uk \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=sparclinux@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=uclinux-dist-devel@blackfin.uclinux.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.