From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Josh Triplett <josh@joshtriplett.org>
Cc: linux-kernel@vger.kernel.org, mingo@elte.hu,
laijs@cn.fujitsu.com, dipankar@in.ibm.com,
akpm@linux-foundation.org, mathieu.desnoyers@polymtl.ca,
dvhltc@us.ibm.com, niv@us.ibm.com, tglx@linutronix.de,
peterz@infradead.org, rostedt@goodmis.org,
Valdis.Kletnieks@vt.edu, dhowells@redhat.com
Subject: Re: [PATCH tip/core/rcu 2/4] rcu: enable fourth level of TREE_RCU hierarchy
Date: Wed, 2 Dec 2009 16:20:30 -0800 [thread overview]
Message-ID: <20091203002030.GB6746@linux.vnet.ibm.com> (raw)
In-Reply-To: <20091202232541.GB5479@feather>
On Wed, Dec 02, 2009 at 03:25:42PM -0800, Josh Triplett wrote:
> On Wed, Dec 02, 2009 at 12:10:14PM -0800, Paul E. McKenney wrote:
> > From: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> >
> > Enable a fourth level of rcu_node hierarchy for TREE_RCU and
> > TREE_PREEMPT_RCU. This is for stress-testing and experiemental
> > purposes only, although in theory this would enable 16,777,216 CPUs
> > on 64-bit systems, though only 1,048,576 CPUs on 32-bit systems.
> > Normal experimental use of this fourth level will normally set
> > CONFIG_RCU_FANOUT=2, requiring a 16-CPU system, though the more
> > adventurous (and more fortunate) experimenters may wish to chose
> > CONFIG_RCU_FANOUT=3 for 81-CPU systems or even CONFIG_RCU_FANOUT=4 for
> > 256-CPU systems.
> >
> > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>
> I like this idea in general, but I have one suggestion on your boot-up
> message:
>
> > --- a/kernel/rcutree.c
> > +++ b/kernel/rcutree.c
> [...]
> > @@ -1877,6 +1878,9 @@ void __init rcu_init(void)
> > #ifdef CONFIG_RCU_CPU_STALL_DETECTOR
> > printk(KERN_INFO "RCU-based detection of stalled CPUs is enabled.\n");
> > #endif /* #ifdef CONFIG_RCU_CPU_STALL_DETECTOR */
> > +#if NUM_RCU_LVL_4 != 0
> > + printk(KERN_INFO "Experimental four-level hierarchy is enabled.\n");
> > +#endif /* #if NUM_RCU_LVL_4 != 0 */
>
> Rather than printing a message when people use the four-level hierarchy,
> how about just printing a message any time someone has set
> CONFIG_RCU_FANOUT manually rather than automatically, and including
> NR_CPUS in that message? That should only occur when testing or when
> trying to do NUMA optimization, and either way it seems worth noting.
Good point! I will keep this patch as is, but I like the idea of having
RCU note anything unusual at boot time, and so have added this to my
todo list. Of course, if CONFIG_RCU_FANOUT starts getting set low as a
matter of course for any (good) reason, then the definition of "anything
unusual" would change, and hence the code would also change.
> Either way the change seems fine to me. With or without that suggested
> change:
>
> Acked-by: Josh Triplett <josh@joshtriplett.org>
Thank you!
Thanx, Paul
next prev parent reply other threads:[~2009-12-03 0:20 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-02 20:09 [PATCH tip/core/rcu 0/4] rcu: preemptible expedited grace periods and cleanups Paul E. McKenney
2009-12-02 20:10 ` [PATCH tip/core/rcu 1/4] rcu: rename "quiet" functions Paul E. McKenney
2009-12-02 23:20 ` Josh Triplett
2009-12-03 13:22 ` [tip:core/rcu] rcu: Rename " tip-bot for Paul E. McKenney
2009-12-02 20:10 ` [PATCH tip/core/rcu 2/4] rcu: enable fourth level of TREE_RCU hierarchy Paul E. McKenney
2009-12-02 23:25 ` Josh Triplett
2009-12-03 0:20 ` Paul E. McKenney [this message]
2009-12-03 13:22 ` [tip:core/rcu] rcu: Enable " tip-bot for Paul E. McKenney
2009-12-02 20:10 ` [PATCH tip/core/rcu 3/4] rcu: add expedited grace-period support for preemptible RCU Paul E. McKenney
2009-12-03 9:26 ` Lai Jiangshan
2009-12-03 14:41 ` Paul E. McKenney
2009-12-03 13:22 ` [tip:core/rcu] rcu: Add " tip-bot for Paul E. McKenney
2009-12-02 20:10 ` [PATCH tip/core/rcu 4/4] rcu: make RCU's CPU-stall detector be default Paul E. McKenney
2009-12-03 13:22 ` [tip:core/rcu] rcu: Make " tip-bot for Paul E. McKenney
2009-12-03 8:53 ` [PATCH tip/core/rcu 0/4] rcu: preemptible expedited grace periods and cleanups Lai Jiangshan
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=20091203002030.GB6746@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=Valdis.Kletnieks@vt.edu \
--cc=akpm@linux-foundation.org \
--cc=dhowells@redhat.com \
--cc=dipankar@in.ibm.com \
--cc=dvhltc@us.ibm.com \
--cc=josh@joshtriplett.org \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@polymtl.ca \
--cc=mingo@elte.hu \
--cc=niv@us.ibm.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--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 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.