[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120522173047.GA8160@linux.vnet.ibm.com>
Date: Tue, 22 May 2012 10:30:47 -0700
From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To: Frederic Weisbecker <fweisbec@...il.com>
Cc: LKML <linux-kernel@...r.kernel.org>,
linaro-sched-sig@...ts.linaro.org,
Alessio Igor Bogani <abogani@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Avi Kivity <avi@...hat.com>,
Chris Metcalf <cmetcalf@...era.com>,
Christoph Lameter <cl@...ux.com>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Geoff Levand <geoff@...radead.org>,
Gilad Ben Yossef <gilad@...yossef.com>,
Hakan Akkan <hakanakkan@...il.com>,
Ingo Molnar <mingo@...nel.org>, Kevin Hilman <khilman@...com>,
Max Krasnyansky <maxk@...lcomm.com>,
Peter Zijlstra <peterz@...radead.org>,
Stephen Hemminger <shemminger@...tta.com>,
Steven Rostedt <rostedt@...dmis.org>,
Sven-Thorsten Dietrich <thebigcorporation@...il.com>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 17/41] rcu: Restart tick if we enqueue a callback in a
nohz/cpuset CPU
On Tue, May 22, 2012 at 10:27:14AM -0700, Paul E. McKenney wrote:
> On Tue, May 01, 2012 at 01:54:51AM +0200, Frederic Weisbecker wrote:
> > If we enqueue an rcu callback, we need the CPU tick to stay
> > alive until we take care of those by completing the appropriate
> > grace period.
> >
> > Thus, when we call_rcu(), send a self IPI that checks rcu_needs_cpu()
> > so that we restore a periodic tick behaviour that can take care of
> > everything.
>
> Ouch, I hadn't considered RCU callbacks being posted from within an
> extended quiescent state. I guess I need to make __call_rcu() either
> complain about this or handle it correctly... It would -usually- be
> harmless, but there is getting to be quite a bit of active machinery
> in the various idle loops, so just assuming that it cannot happen is
> probably getting to be an obsolete assumption.
Adaptive ticks does restart the tick upon entering the kernel, correct?
If so, wouldn't the return to userspace cause adaptive tick to automatically
handle a callback posted from within the kernel?
(And yes, I still need to handle the possibility of callbacks being posted
from the idle loop, but that is a different extended quiescent state.)
Thanx, Paul
> > Signed-off-by: Frederic Weisbecker <fweisbec@...il.com>
> > Cc: Alessio Igor Bogani <abogani@...nel.org>
> > Cc: Andrew Morton <akpm@...ux-foundation.org>
> > Cc: Avi Kivity <avi@...hat.com>
> > Cc: Chris Metcalf <cmetcalf@...era.com>
> > Cc: Christoph Lameter <cl@...ux.com>
> > Cc: Daniel Lezcano <daniel.lezcano@...aro.org>
> > Cc: Geoff Levand <geoff@...radead.org>
> > Cc: Gilad Ben Yossef <gilad@...yossef.com>
> > Cc: Hakan Akkan <hakanakkan@...il.com>
> > Cc: Ingo Molnar <mingo@...nel.org>
> > Cc: Kevin Hilman <khilman@...com>
> > Cc: Max Krasnyansky <maxk@...lcomm.com>
> > Cc: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>
> > Cc: Peter Zijlstra <peterz@...radead.org>
> > Cc: Stephen Hemminger <shemminger@...tta.com>
> > Cc: Steven Rostedt <rostedt@...dmis.org>
> > Cc: Sven-Thorsten Dietrich <thebigcorporation@...il.com>
> > Cc: Thomas Gleixner <tglx@...utronix.de>
> > ---
> > kernel/rcutree.c | 7 +++++++
> > 1 files changed, 7 insertions(+), 0 deletions(-)
> >
> > diff --git a/kernel/rcutree.c b/kernel/rcutree.c
> > index 3fffc26..b8d300c 100644
> > --- a/kernel/rcutree.c
> > +++ b/kernel/rcutree.c
> > @@ -1749,6 +1749,13 @@ __call_rcu(struct rcu_head *head, void (*func)(struct rcu_head *rcu),
> > else
> > trace_rcu_callback(rsp->name, head, rdp->qlen);
> >
> > + /* Restart the timer if needed to handle the callbacks */
> > + if (cpuset_adaptive_nohz()) {
> > + /* Make updates on nxtlist visible to self IPI */
> > + barrier();
> > + smp_cpuset_update_nohz(smp_processor_id());
> > + }
> > +
> > /* If interrupts were disabled, don't dive into RCU core. */
> > if (irqs_disabled_flags(flags)) {
> > local_irq_restore(flags);
> > --
> > 1.7.5.4
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists