public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: paulmck@linux.vnet.ibm.com
Cc: linux-kernel@vger.kernel.org, cl@linux-foundation.org,
	mingo@elte.hu, manfred@colorfullife.com, dipankar@in.ibm.com,
	josht@linux.vnet.ibm.com, schamp@sgi.com, niv@us.ibm.com,
	dvhltc@us.ibm.com, ego@in.ibm.com, laijs@cn.fujitsu.com,
	rostedt@goodmis.org, peterz@infradead.org,
	penberg@cs.helsinki.fi, andi@firstfloor.org, tglx@linutronix.de
Subject: Re: [PATCH -tip] v10 scalable classic RCU implementation
Date: Tue, 16 Dec 2008 18:03:13 -0800	[thread overview]
Message-ID: <20081216180313.23bcd252.akpm@linux-foundation.org> (raw)
In-Reply-To: <20081217003744.GA26660@linux.vnet.ibm.com>

On Tue, 16 Dec 2008 16:37:44 -0800 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:

> Hello!
> 
> This patch fixes a long-standing performance bug in classic RCU that
> results in massive internal-to-RCU lock contention on systems with
> more than a few hundred CPUs.  Although this patch creates a separate
> flavor of RCU for ease of review and patch maintenance, it is intended
> to replace classic RCU.
> 
> This patch still handles stress better than does mainline, so I am still
> calling it ready for inclusion.  This patch is against the -tip tree.
> Nevertheless, experience on an actual 1000+ CPU machine would still be
> most welcome.
> 
> Most of the changes noted below were found while creating an rcutiny
> (which should permit ejecting the current rcuclassic) and while doing
> detailed line-by-line documentation.
> 
> Updates from v9 (http://lkml.org/lkml/2008/12/2/334):
> 
> o	Fixes from remainder of line-by-line code walkthrough,
> 	including comment spelling, initialization, undesirable
> 	narrowing due to type conversion, removing redundant memory
> 	barriers, removing redundant local-variable initialization,
> 	and removing redundant local variables.
> 
> 	I do not believe that any of these fixes address the CPU-hotplug
> 	issues that Andi Kleen was seeing, but please do give it a whirl
> 	in case the machine is smarter than I am.
> 
> 	A writeup from the walkthrough may be found at the following
> 	URL, in case you are suffering from terminal insomnia or
> 	masochism:
> 
> 	http://www.kernel.org/pub/linux/kernel/people/paulmck/tmp/rcutree-walkthrough.2008.12.16a.pdf
> 
> o	Made rcutree tracing use seq_file, as suggested some time
> 	ago by Lai Jiangshan.
> 
> o	Added a .csv variant of the rcudata debugfs trace file, to allow
> 	people having thousands of CPUs to drop the data into
> 	a spreadsheet.	Tested with oocalc and gnumeric.  Updated
> 	documentation to suit.
> 
> Updates from v8 (http://lkml.org/lkml/2008/11/15/139):
> Updates from v7 (http://lkml.org/lkml/2008/10/10/291):
> Updates from v6 (http://lkml.org/lkml/2008/9/23/448):
> Updates from v5 (http://lkml.org/lkml/2008/9/15/92, bad subject line):
> Updates from v4 for those missing v5 given its bad subject line:

It strikes me that this code is at the level of maturity where it
should have been in linux-next months ago.

> 
> To build, start with 2.6.28-rc3, and apply:
> 
> 	http://www.rdrop.com/users/paulmck/patches/linux-2.6-tip.2008.11.29a.patch
> 	http://www.rdrop.com/users/paulmck/patches/2.6.28-rc3-tip-treeRCU-7.patch
> 
> The former gets you to commit #29cbda77a67cf263d636feea65d3bbc9c7de2e24
> in /tip/core/rcu in the -tip tree, and the latter is the following patch.
> 
> Thoughts?

Merge it?

> +choice
> +	prompt "RCU Implementation"
> +	default CLASSIC_RCU

But toggle that.

> +config CLASSIC_RCU
> +	bool "Classic RCU"
> +	help
> +	  This option selects the classic RCU implementation that is
> +	  designed for best read-side performance on non-realtime
> +	  systems.
> +	  
> +	  Select this option if you are unsure.
> +
> +config TREE_RCU
> +	bool "Tree-based hierarchical RCU"
> +	help
> +	  This option selects the RCU implementation that is
> +	  designed for very large SMP system with hundreds or
> +	  thousands of CPUs.
> +

If it blows up, we can trivially disable it in config, yes?

> Documentation/RCU/00-INDEX             |    2 
> Documentation/RCU/trace.txt            |  413 ++++++++
> arch/powerpc/platforms/pseries/rtasd.c |    4 
> include/linux/hardirq.h                |   14 
> include/linux/rcupdate.h               |   10 
> include/linux/rcutree.h                |  329 +++++++
> init/Kconfig                           |   18 
> kernel/Kconfig.preempt                 |   62 +
> kernel/Makefile                        |    6 
> kernel/rcupreempt.c                    |   10 
> kernel/rcupreempt_trace.c              |   10 
> kernel/rcutree.c                       | 1535 +++++++++++++++++++++++++++++++++
> kernel/rcutree_trace.c                 |  271 +++++
> kernel/softirq.c                       |    5 
> lib/Kconfig.debug                      |   13 
> 15 files changed, 2671 insertions(+), 31 deletions(-)

What's the plan for removal of the classic RCU code?  (asap, please. 
No more slabs!)


  reply	other threads:[~2008-12-17  2:05 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-02 22:21 [PATCH -tip] v9 scalable classic RCU implementation Paul E. McKenney
2008-12-02 23:31 ` Andi Kleen
2008-12-02 23:51   ` Paul E. McKenney
2008-12-03  0:18     ` Andi Kleen
2008-12-03  0:47       ` Paul E. McKenney
2008-12-03  1:10         ` Andi Kleen
2008-12-03  1:36           ` Paul E. McKenney
2008-12-18 22:54             ` Paul E. McKenney
2008-12-19  1:29               ` Andi Kleen
2008-12-19  1:49                 ` Paul E. McKenney
2008-12-03  8:40         ` Ingo Molnar
2008-12-17  0:37 ` [PATCH -tip] v10 " Paul E. McKenney
2008-12-17  2:03   ` Andrew Morton [this message]
2008-12-17 19:49     ` 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=20081216180313.23bcd252.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=cl@linux-foundation.org \
    --cc=dipankar@in.ibm.com \
    --cc=dvhltc@us.ibm.com \
    --cc=ego@in.ibm.com \
    --cc=josht@linux.vnet.ibm.com \
    --cc=laijs@cn.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manfred@colorfullife.com \
    --cc=mingo@elte.hu \
    --cc=niv@us.ibm.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=penberg@cs.helsinki.fi \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=schamp@sgi.com \
    --cc=tglx@linutronix.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox