Re: [RFC PATCH 07/15] nohz_task: Restart tick when RCU forces nohz task cpu quiescent state

[Frederic Weisbecker <fweisbec@gmail.com>]

On Tue, Dec 21, 2010 at 08:41:14AM +0100, Peter Zijlstra wrote:
> On Tue, 2010-12-21 at 00:52 +0100, Frederic Weisbecker wrote:
> > On Mon, Dec 20, 2010 at 05:02:09PM +0100, Peter Zijlstra wrote:
> > > On Mon, 2010-12-20 at 16:24 +0100, Frederic Weisbecker wrote:
> > > > If a cpu is in nohz mode due to a nohz task running, then
> > > > it is not able to notify quiescent states requested by other
> > > > CPUs.
> > > > 
> > > > Then restart the tick to remotely force the quiescent states on the
> > > > nohz task cpus.
> > > 
> > > -ENOPARSE.. if its in NOHZ state, it couldn't possibly need to
> > > participate in the quiescent state machine because the cpu is in a
> > > quiescent state and has 0 RCU activity.
> > 
> > 
> > But it can be in nohz state in the kernel in which case it can have
> > any RCU activity.
> 
> That still doesn't make sense.. if you're in nohz state there shouldn't
> be any rcu activity, otherwise its not nohz is it?
> 
> 

nohz only means that the tick is stopped, that we don't have
anymore a periodic but purely on need event.

Now rcu takes appropriate action to that new state accordingly.
If it's idle or in userspace, then it can enter into extended
quiescent state. If not then it can't.

So nohz and extended qs must be two different things now.