From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Lai Jiangshan <laijs@cn.fujitsu.com>, Ingo Molnar <mingo@elte.hu>,
Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [PATCH 1/2] rcu: Don't chase unnecessary quiescent states after extended grace periods
Date: Tue, 23 Nov 2010 16:58:20 -0800 [thread overview]
Message-ID: <20101124005820.GH8056@linux.vnet.ibm.com> (raw)
In-Reply-To: <1290558673-23580-2-git-send-crap-fweisbec@gmail.com>
On Wed, Nov 24, 2010 at 01:31:12AM +0100, Frederic Weisbecker wrote:
> When a cpu is in an extended quiescent state, which includes idle
> nohz or CPU offline, others CPUs will take care of the grace periods
> on its behalf.
>
> When this CPU exits its extended quiescent state, it will catch up
> with the last started grace period and start chasing its own
> quiescent states to end the current grace period.
>
> However in this case we always start to track quiescent states if the
> grace period number has changed since we started our extended
> quiescent state. And we do this because we always assume that the last
> grace period is not finished and needs us to complete it, which is
> sometimes wrong.
>
> This patch verifies if the last grace period has been completed and
> if so, start hunting local quiescent states like we always did.
> Otherwise don't do anything, this economizes us some work and
> an unnecessary softirq.
Interesting approach! I can see how this helps in the case where the
CPU just came online, but I don't see it in the nohz case, because the
nohz case does not update the rdp->completed variable. In contrast,
the online path calls rcu_init_percpu_data() which sets up this variable.
So, what am I missing here?
Thanx, Paul
PS. It might well be worthwhile for the online case alone, but
the commit message does need to be accurate.
> Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
> Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
> Cc: Ingo Molnar <mingo@elte.hu>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Cc: Steven Rostedt <rostedt@goodmis.org>
> ---
> kernel/rcutree.c | 13 +++++++++++--
> 1 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/rcutree.c b/kernel/rcutree.c
> index ccdc04c..5f038a1 100644
> --- a/kernel/rcutree.c
> +++ b/kernel/rcutree.c
> @@ -620,8 +620,17 @@ static void __init check_cpu_stall_init(void)
> static void __note_new_gpnum(struct rcu_state *rsp, struct rcu_node *rnp, struct rcu_data *rdp)
> {
> if (rdp->gpnum != rnp->gpnum) {
> - rdp->qs_pending = 1;
> - rdp->passed_quiesc = 0;
> + /*
> + * Another CPU might have taken take of this new grace period
> + * while we were idle and handled us as in an extended quiescent
> + * state. In that case, we don't need to chase a local quiescent
> + * state, otherwise:
> + */
> + if (rdp->completed != rnp->gpnum) {
> + rdp->qs_pending = 1;
> + rdp->passed_quiesc = 0;
> + }
> +
> rdp->gpnum = rnp->gpnum;
> }
> }
> --
> 1.7.1
>
next prev parent reply other threads:[~2010-11-24 0:58 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-24 0:31 [PATCH 0/2] rcu: Fix series of spurious RCU softirqs Frederic Weisbecker
2010-11-24 0:31 ` [PATCH 1/2] rcu: Don't chase unnecessary quiescent states after extended grace periods Frederic Weisbecker
2010-11-24 0:58 ` Paul E. McKenney [this message]
2010-11-24 2:29 ` Frederic Weisbecker
2010-11-24 2:33 ` Frederic Weisbecker
2010-11-24 6:22 ` Paul E. McKenney
2010-11-24 13:48 ` Frederic Weisbecker
2010-11-24 14:42 ` Paul E. McKenney
2010-11-24 15:45 ` Frederic Weisbecker
2010-11-24 16:15 ` Paul E. McKenney
2010-11-24 17:38 ` Frederic Weisbecker
2010-11-24 18:20 ` Paul E. McKenney
2010-11-24 20:22 ` Paul E. McKenney
2010-11-24 20:45 ` Frederic Weisbecker
2010-11-24 21:19 ` Paul E. McKenney
2010-11-24 21:50 ` Frederic Weisbecker
2010-11-24 22:42 ` Frederic Weisbecker
2010-11-25 14:56 ` Paul E. McKenney
2010-11-26 14:06 ` Frederic Weisbecker
2010-11-29 23:06 ` Paul E. McKenney
2010-11-24 0:31 ` [PATCH 2/2] rcu: Stop checking quiescent states after grace period completion from remote Frederic Weisbecker
2010-11-24 1:03 ` Paul E. McKenney
2010-11-25 3:42 ` [PATCH 0/2] rcu: Fix series of spurious RCU softirqs Lai Jiangshan
2010-11-25 7:38 ` Frederic Weisbecker
2010-11-25 8:35 ` Lai Jiangshan
2010-11-25 9:27 ` Frederic Weisbecker
2010-11-25 14:58 ` 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=20101124005820.GH8056@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=a.p.zijlstra@chello.nl \
--cc=fweisbec@gmail.com \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--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.