Messages in this thread | | | Subject | Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods | From | "Li, Aubrey" <> | Date | Thu, 20 Jul 2017 09:40:49 +0800 |
| |
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
| |