Re: [PATCH RFC tip/core/rcu 19/28] nohz: Allow rcu extended quiescent state handling seperately from tick stop

[Peter Zijlstra <peterz@infradead.org>]

On Wed, 2011-11-09 at 17:48 +0100, Frederic Weisbecker wrote:
> > Having four API members rather than the current six does seem quite
> > attractive to me.  Frederic, any reason why this approach won't work?
> 
> The approach I took might sound silly but it's mostly an optimization:
> 
> I did the *_norcu() variant mostly to be able to keep rcu_idle_enter()
> call under the same local_irq_disable() section.
> 
> This way we can't have an interrupt in between that can needlessly perform
> RCU work (and trigger the softirq in the worst case), delaying the point
> where we actually put the CPU to sleep. 

I'm not sure I get what you're saying. A fully decoupled RCU/NO_HZ API
looks like:

  rcu_idle_enter();
  rcu_idle_exit();

  tick_nohz_idle_enter();
  tick_nohz_idle_exit();

And done you are, no funny interactions, 4 functions.

There is no _norcu variant simply because nohz will never touch rcu. If
you want the old coupled behaviour simply call both
tick_nohz_idle_enter() and rcu_idle_enter().