[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120523160629.GJ1663@somewhere>
Date: Wed, 23 May 2012 18:06:33 +0200
From: Frederic Weisbecker <fweisbec@...il.com>
To: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.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 11/41] nohz/cpuset: Don't turn off the tick if rcu needs
it
On Wed, May 23, 2012 at 08:15:42AM -0700, Paul E. McKenney wrote:
> On Wed, May 23, 2012 at 03:52:09PM +0200, Frederic Weisbecker wrote:
> > > > +#ifdef CONFIG_CPUSETS_NO_HZ
> > > > +static bool can_stop_adaptive_tick(void)
> > > > +{
> > > > + if (!sched_can_stop_tick())
> > > > + return false;
> > > > +
> > > > + /* Is there a grace period to complete ? */
> > > > + if (rcu_pending(smp_processor_id()))
> > >
> > > You lost me on this one. Why can't this be rcu_needs_cpu()?
> >
> > We already have an rcu_needs_cpu() check in tick_nohz_stop_sched_tick()
> > that prevents the tick to shut down if the CPU has local callbacks to handle.
> >
> > The rcu_pending() check is there in case some other CPU is waiting for the
> > current one to help completing a grace period, by reporting a quiescent state
> > for example. This happens because we may stop the tick in the kernel, not only
> > userspace. And if we are in the kernel, we still need to be part of the global
> > state machine.
>
> Ah! But RCU will notice that the CPU is in dyntick-idle mode, and will
> therefore take any needed quiescent-state action on that CPU's behalf.
> So there should be no need to call rcu_pending() anywhere outside of the
> RCU core code.
No. If the tick is stopped and we are in the kernel, we may be using RCU
anytime, so we need to be part of the RCU core.
--
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