On 2017/7/19 22:48, Paul E. McKenney wrote: > On Wed, Jul 19, 2017 at 01:44:06PM +0800, Li, Aubrey wrote: >> On 2017/7/18 23:20, Paul E. McKenney wrote: >> >>>> 2) for rcu idle enter/exit, I measured the details which Paul provided, and >>>> the result matches with what I have measured before, nothing notable found. >>>> But it still makes more sense if we can make rcu idle enter/exit hooked >>>> with >>>> tick off. (it's possible other workloads behave differently) >>> >>> Again, assuming that RCU is informed of CPUs in the kernel, regardless >>> of whether or not the tick is on that that point in time. >>> >> Yeah, I see, no problem for a normal idle. >> >> But for a short idle, we want to return to the task ASAP. Even though RCU >> cost >> is not notable, it would still be better for me if we can save some cycles in >> idle entry and idle exit. >> >> Do we have any problem if we skip RCU idle enter/exit under a fast idle >> scenario? >> My understanding is, if tick is not stopped, then we don't need inform RCU in >> idle path, it can be informed in irq exit. > > Indeed, the problem arises when the tick is stopped.
My question is, does problem arise when the tick is *not* stopped (skipping nohz idle)? instead of static void cpuidle_idle_call() { rcu_idle_enter() ...... rcu_idle_exit() } I want static void cpuidle_idle_call() { if (tick stopped) rcu_idle_enter() ...... if (tick stopped) rcu_idle_exit() } Or checking tick stop can be put into rcu_idle_enter/exit Thanks, -Aubrey