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,
niv@us.ibm.com, tglx@linutronix.de, peterz@infradead.org,
rostedt@goodmis.org, dhowells@redhat.com, edumazet@google.com,
darren@dvhart.com, fweisbec@gmail.com, sbw@mit.edu
Subject: Re: [PATCH tip/core/rcu 02/11] rcu: Expedite during suspend and resume only on smallish systems
Date: Sun, 18 Aug 2013 17:32:43 -0700 [thread overview]
Message-ID: <20130819003242.GS29406@linux.vnet.ibm.com> (raw)
In-Reply-To: <20130818031831.GM28923@leaf>
On Sat, Aug 17, 2013 at 08:18:32PM -0700, Josh Triplett wrote:
> On Sat, Aug 17, 2013 at 06:37:47PM -0700, Paul E. McKenney wrote:
> > From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> >
> > Expedited grace periods are of dubious benefit on very large systems,
> > so this commit restricts their automated use during suspend and resume
> > to systems of 256 or fewer CPUs.
> >
> > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>
> This seems odd. If expedited grace periods don't help on large systems,
> shouldn't you just compile them out entirely and ignore rcu_expedited,
> rather than just in this one special case?
Longer term, a bunch of stuff will need optimization for larger systems.
Expedited RCU grace periods, rcu_barrier(), possibly even grace-period
initialization and cleanup. Also smp_call_function(), along with other
primitives that have broadcast semantics. These changes would allow
this hack to be removed.
The most straightforward approach would be to provision helper kthreads,
increasing the number of helper kthreads with the number of CPUs. But
I would like to see actual problems due to the lack of scalability before
adding more complexity to RCU. ;-)
> In any case, if this patch still makes sense, please squash it into the
> previous one.
Fair enough, done!
Thanx, Paul
next prev parent reply other threads:[~2013-08-19 0:32 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-18 1:37 [PATCH tip/core/rcu 0/11] Fixes for 3.12 Paul E. McKenney
2013-08-18 1:37 ` [PATCH tip/core/rcu 01/11] rcu: Expedite grace periods during suspend/resume Paul E. McKenney
2013-08-18 1:37 ` [PATCH tip/core/rcu 02/11] rcu: Expedite during suspend and resume only on smallish systems Paul E. McKenney
2013-08-18 3:18 ` Josh Triplett
2013-08-19 0:32 ` Paul E. McKenney [this message]
2013-08-18 1:37 ` [PATCH tip/core/rcu 03/11] rcu: Simplify debug-objects fixups Paul E. McKenney
2013-08-18 1:37 ` [PATCH tip/core/rcu 04/11] debugobjects: Make debug_object_activate() return status Paul E. McKenney
2013-08-18 1:37 ` [PATCH tip/core/rcu 05/11] rcu: Make call_rcu() leak callbacks for debug-object errors Paul E. McKenney
2013-08-18 1:37 ` [PATCH tip/core/rcu 06/11] rcu: Switch to exedited grace periods for suspend as well as hibernation Paul E. McKenney
2013-08-18 3:20 ` Josh Triplett
2013-08-19 0:33 ` Paul E. McKenney
2013-08-18 1:37 ` [PATCH tip/core/rcu 07/11] rcu: Avoid redundant grace-period kthread wakeups Paul E. McKenney
2013-08-18 1:37 ` [PATCH tip/core/rcu 08/11] rculist: list_first_or_null_rcu() should use list_entry_rcu() Paul E. McKenney
2013-08-18 1:37 ` [PATCH tip/core/rcu 09/11] rcu: Select IRQ_WORK from TREE_PREEMPT_RCU Paul E. McKenney
2013-08-18 1:37 ` [PATCH tip/core/rcu 10/11] rcu: Simplify _rcu_barrier() processing Paul E. McKenney
2013-08-18 1:37 ` [PATCH tip/core/rcu 11/11] jiffies: Avoid undefined behavior from signed overflow Paul E. McKenney
2013-08-18 3:23 ` Josh Triplett
2013-08-19 0:41 ` Paul E. McKenney
2013-08-19 1:20 ` Josh Triplett
2013-08-19 4:14 ` Paul E. McKenney
2013-08-18 3:17 ` [PATCH tip/core/rcu 01/11] rcu: Expedite grace periods during suspend/resume Josh Triplett
2013-08-18 9:34 ` Borislav Petkov
2013-08-19 0:29 ` Paul E. McKenney
2013-08-19 9:18 ` Borislav Petkov
2013-08-18 3:24 ` [PATCH tip/core/rcu 0/11] Fixes for 3.12 Josh Triplett
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=20130819003242.GS29406@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=darren@dvhart.com \
--cc=dhowells@redhat.com \
--cc=dipankar@in.ibm.com \
--cc=edumazet@google.com \
--cc=fweisbec@gmail.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=sbw@mit.edu \
--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;
as well as URLs for NNTP newsgroup(s).