lkml.org 
[lkml]   [2017]   [Jul]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC PATCH v1 00/11] Create fast idle path for short idle periods
From
Date
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)

\
 
 \ /
  Last update: 2017-07-20 23:22    [W:0.448 / U:0.432 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site