linux-kernel - Re: [PATCH v6 2/2] cpuidle: teo: Introduce util-awareness

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]

Date: Mon, 17 Jun 2024 09:13:19 +0100
From: Lukasz Luba <lukasz.luba@....com>
To: Qais Yousef <qyousef@...alina.io>
Cc: Kajetan Puchalski <kajetan.puchalski@....com>, rafael@...nel.org,
 daniel.lezcano@...aro.org, Dietmar.Eggemann@....com, dsmythies@...us.net,
 yu.chen.surf@...il.com, linux-pm@...r.kernel.org,
 linux-kernel@...r.kernel.org, Peter Zijlstra <peterz@...radead.org>,
 Ulf Hansson <ulf.hansson@...aro.org>,
 Vincent Guittot <vincent.guittot@...aro.org>, Todd Kjos <tkjos@...gle.com>,
 "wvw@...gle.com" <wvw@...gle.com>
Subject: Re: [PATCH v6 2/2] cpuidle: teo: Introduce util-awareness



On 6/16/24 22:48, Qais Yousef wrote:
> On 06/12/24 08:53, Lukasz Luba wrote:
> 
>>> This won't help. We tried different values, unfortunately the logic is flawed.
>>> Utilization value on its own says nothing about the idleness of the system.
>>
>> This is not true. When you up-migrate a task to big CPU, then CPU idle
>> gov can instantly benefit from utilization information and won't make
>> mistake based on old local history and won't use deep idle state.
>> So migrating the utilization from one CPU to another CPU says a lot
>> about the idleness to that destination CPU.
> 
> You can migrate a 1024 tasks to a bigger core, but it could run for 3ms and
> sleep for 40ms. So unfortunately I have to disagree with you here.
> Generally a high util value doesn't mean we are not going to be idle long
> enough to satisfy min_residency of the CPU.

Please don't tell me theoretical workloads. We both know that the
display pipeline requires vsync every 16ms at least and on >100Hz
display it will be shorter.

> 
>> When Christian removed the util he got -4.5% lower score in GB5, so
>> this util has impact [1].
> 
> We need the idle governor to help with power saving. We can disable DVFS and
> all idle states and always get a better performance.
> 
> The residency is ~50% worse on some clusters with this change. Overall power
> impact is 2-4% in many use cases.

As I said, please provide power numbers - otherwise this discussion has
no value.

Also, please respond question from my previous email by who you mean
'we' when you claim power regression (also not showing the power
numbers).

This is really not the way how serious development should be done.

> 
> GB5 is not really a representative use case to measure the usefulness of the
> idle governor. Task placement to avoid the cost of idle exit latency is
> a completely different problem.

GB5 or GB6 are benchmarks that people use when they compare performance
of the phones or laptops and it's very important. If you follow the
evolution of modern processors (from different uArch) you will
notice that a new generation provides sometimes ~10% improvement to that
GB5 score in single-thread mode (at same freq).

Performance results are important as well as power in other tests.