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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <970eb7df-1a42-9ed7-a69d-58af8c206f7b@linux.intel.com>
Date:   Thu, 20 Jul 2017 06:48:41 -0700
From:   Arjan van de Ven <arjan@...ux.intel.com>
To:     Thomas Gleixner <tglx@...utronix.de>,
        "Li, Aubrey" <aubrey.li@...ux.intel.com>
Cc:     Andi Kleen <ak@...ux.intel.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Frederic Weisbecker <fweisbec@...il.com>,
        Christoph Lameter <cl@...ux.com>,
        Aubrey Li <aubrey.li@...el.com>, len.brown@...el.com,
        rjw@...ysocki.net, tim.c.chen@...ux.intel.com,
        paulmck@...ux.vnet.ibm.com, yang.zhang.wz@...il.com,
        x86@...nel.org, linux-kernel@...r.kernel.org,
        daniel.lezcano@...aro.org
Subject: Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

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)