From: Peter Zijlstra <peterz@infradead.org>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Josh Triplett <josh@joshtriplett.org>,
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, rostedt@goodmis.org,
Valdis.Kletnieks@vt.edu, dhowells@redhat.com,
edumazet@google.com, darren@dvhart.com, fweisbec@gmail.com,
sbw@mit.edu
Subject: Re: [PATCH tip/core/rcu 6/7] rcu: Drive quiescent-state-forcing delay from HZ
Date: Wed, 15 May 2013 10:56:39 +0200 [thread overview]
Message-ID: <20130515085639.GD10510@laptop.programming.kicks-ass.net> (raw)
In-Reply-To: <20130514154728.GC4442@linux.vnet.ibm.com>
On Tue, May 14, 2013 at 08:47:28AM -0700, Paul E. McKenney wrote:
> On Tue, May 14, 2013 at 04:51:20PM +0200, Peter Zijlstra wrote:
> > > In theory, yes. In practice, this requires lots of lock acquisitions
> > > and releases on large systems, including some global locks. The weight
> > > could be reduced, but...
> > >
> > > What I would like to do instead would be to specify expedited grace
> > > periods during boot.
> >
> > But why, surely going idle without any RCU callbacks isn't completely unheard
> > of, even outside of the boot process?
>
> Yep, and RCU has special-cased that for quite some time.
>
> > Being able to quickly drop out of the RCU state machinery would be a good thing IMO.
>
> And this is currently possible -- this is the job of rcu_idle_enter()
> and friends. And it works well, at least when I get my "if" statements
> set up correctly (hence the earlier patch).
>
> Or are you seeing a slowdown even with that earlier patch applied? If so,
> please let me know what you are seeing.
I'm not running anything in particular, except maybe a broken mental
model of RCU ;-)
So what I'm talking about is the !rcu_cpu_has_callbacks() case, where
there's absolutely nothing for RCU to do except tell the state machine
its no longer participating.
Your patch to rcu_needs_cpu() frobbing the lazy condition is after that
and thus irrelevant for this AFAICT.
Now as far as I can see, rcu_needs_cpu() will return false in this case;
allowing the cpu to enter NO_HZ state. We then call rcu_idle_enter()
which would call rcu_eqs_enter(). Which should put the CPU in extended
quiescent state.
However, you're still running into these FQSs delaying boot. Why is
that? Is that because rcu_eqs_enter() doesn't really do enough?
The thing is, if all other CPUs are idle, detecting the end of a grace
period should be rather trivial and not involve FQSs and thus be tons
faster.
Clearly I'm missing something obvious and not communicating right or so.
next prev parent reply other threads:[~2013-05-15 9:01 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-12 23:18 [PATCH tip/core/rcu 0/7] RCU fixes for 3.11 Paul E. McKenney
2013-04-12 23:19 ` [PATCH tip/core/rcu 1/7] rcu: Convert rcutree.c printk calls Paul E. McKenney
2013-04-12 23:19 ` [PATCH tip/core/rcu 2/7] rcu: Convert rcutree_plugin.h " Paul E. McKenney
2013-04-12 23:19 ` [PATCH tip/core/rcu 3/7] rcu: Kick adaptive-ticks CPUs that are holding up RCU grace periods Paul E. McKenney
2013-04-13 14:06 ` Frederic Weisbecker
2013-04-13 15:19 ` Paul E. McKenney
2013-04-12 23:19 ` [PATCH tip/core/rcu 4/7] rcu: Don't allocate bootmem from rcu_init() Paul E. McKenney
2013-04-12 23:19 ` [PATCH tip/core/rcu 5/7] rcu: Remove "Experimental" flags Paul E. McKenney
2013-04-12 23:19 ` [PATCH tip/core/rcu 6/7] rcu: Drive quiescent-state-forcing delay from HZ Paul E. McKenney
2013-04-12 23:54 ` Josh Triplett
2013-04-13 6:38 ` Paul E. McKenney
2013-04-13 18:18 ` Josh Triplett
2013-04-13 19:34 ` Paul E. McKenney
2013-04-13 19:53 ` Josh Triplett
2013-04-13 22:09 ` Paul E. McKenney
2013-04-14 6:10 ` Paul E. McKenney
2013-05-14 12:20 ` Peter Zijlstra
2013-05-14 14:12 ` Paul E. McKenney
2013-05-14 14:51 ` Peter Zijlstra
2013-05-14 15:47 ` Paul E. McKenney
2013-05-15 8:56 ` Peter Zijlstra [this message]
2013-05-15 9:02 ` Peter Zijlstra
2013-05-15 17:31 ` Paul E. McKenney
2013-05-16 9:45 ` Peter Zijlstra
2013-05-16 13:22 ` Paul E. McKenney
2013-05-21 9:45 ` Peter Zijlstra
2013-05-21 16:54 ` Paul E. McKenney
2013-05-15 16:37 ` Paul E. McKenney
2013-05-16 9:37 ` Peter Zijlstra
2013-05-16 13:13 ` Paul E. McKenney
2013-05-15 9:20 ` Ingo Molnar
2013-05-15 15:44 ` Paul E. McKenney
2013-05-28 10:07 ` Ingo Molnar
2013-05-29 1:29 ` Paul E. McKenney
2013-04-15 2:03 ` Paul Mackerras
2013-04-15 17:26 ` Paul E. McKenney
2013-04-12 23:19 ` [PATCH tip/core/rcu 7/7] rcu: Merge adjacent identical ifdefs Paul E. McKenney
2013-04-13 0:01 ` [PATCH tip/core/rcu 0/7] RCU fixes for 3.11 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=20130515085639.GD10510@laptop.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=Valdis.Kletnieks@vt.edu \
--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=paulmck@linux.vnet.ibm.com \
--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
all inboxes | Powered by JetHome®