Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

[Arjan van de Ven]

On 7/20/2017 1:11 AM, Thomas Gleixner wrote:
> On Thu, 20 Jul 2017, Li, Aubrey wrote:
> > Don't get me wrong, even if a fast path is acceptable, we still need to
> > figure out if the coming idle is short and when to switch. I'm just worried
> > about if irq timings is not an ideal statistics, we have to skip it too.
>
> There is no ideal solution ever.
>
> Lets sit back and look at that from the big picture first before dismissing
> a particular item upfront.
>
> The current NOHZ implementation does:
>
>     predict = nohz_predict(timers, rcu, arch, irqwork);
>
>     if ((predict - now) > X)
>     	stop_tick()
>
> The C-State machinery does something like:
>
>     predict = cstate_predict(next_timer, scheduler);
>
>     cstate = cstate_select(predict);
>
> That disconnect is part of the problem. What we really want is:
>
>     predict = idle_predict(timers, rcu, arch, irqwork, scheduler, irq timings);

two separate predictors is clearly a recipe for badness.

(likewise, C and P states try to estimate "performance sensitivity" and sometimes estimate in opposite directions)



to be honest, performance sensitivity estimation is probably 10x more critical for C state
selection than idle duration; a lot of modern hardware will do the energy efficiency stuff
in a microcontroller when it coordinates between multiple cores in the system on C and P states.

(both x86 and ARM have such microcontroller nowadays, at least for the higher performance
designs)