Messages in this thread | | | Date | Mon, 26 Sep 2011 09:02:06 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH 4/7] nohz: Allow rcu extended quiescent state handling seperately from tick stop |
| |
On Mon, Sep 26, 2011 at 12:44:44PM +0200, Peter Zijlstra wrote: > On Mon, 2011-09-26 at 12:19 +0200, Frederic Weisbecker wrote: > > It is assumed that rcu won't be used once we switch to tickless > > mode and until we restart the tick. However this is not always > > true, as in x86-64 where we dereference the idle notifiers after > > the tick is stopped. > > > > To prepare for fixing this, add a parameter to tick_nohz_enter_idle() > > named "rcu_ext_qs" that tells whether we want to enter RCU extended > > quiescent state at the same time we stop the tick. > > > > If no use of RCU is made in the idle loop between > > tick_nohz_enter_idle() and tick_nohz_exit_idle() calls, the parameter > > must be set to true and the arch doesn't need to call rcu_enter_nohz() > > and rcu_exit_nohz() explicitly. > > > > Otherwise the parameter must be set to false and the arch is > > responsible of calling: > > > > - rcu_enter_nohz() after its last use of RCU before the CPU is put > > to sleep. > > - rcu_exit_nohz() before the first use of RCU after the CPU is woken > > up. > > I can't say this really makes sense: > > tick_nohz_idle_enter(false); > > reads like, don't enter nohz state, not: enter nohz state but don't > enter rcu-nohz state. > > I realize you want to keep the per-arch frobbing low, but since you're > already touching all of them, I think its more important to keep the > functions readable. > > Why not simply fully split nohz and rcu and modify all idle routines > with both calls?
This might well be the correct thing to do, but one thing that gives me pause is that some architectures have a large number of idle routines. If such an architecture can use tick_nohz_idle_enter(true), then that architecture needs only one change rather than one change to each of potentially many idle loops.
Would your readability concerns be addressed by something like the following?
#define RCU_NO_HZ_LATER 0 #define RCU_NO_HZ_NOW 1
Then we would have one of the following:
tick_nohz_idle_enter(RCU_NO_HZ_LATER); tick_nohz_idle_enter(RCU_NO_HZ_NOW);
Thanx, Paul
| |