linux-kernel - Re: [PATCH 1/4] sched: cpufreq: Rename map_util_perf to apply_dvfs

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, 21 Aug 2023 18:38:25 +0200
From:   Dietmar Eggemann <dietmar.eggemann@....com>
To:     Qais Yousef <qyousef@...alina.io>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        Ingo Molnar <mingo@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>
Cc:     linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Lukasz Luba <lukasz.luba@....com>
Subject: Re: [PATCH 1/4] sched: cpufreq: Rename map_util_perf to
 apply_dvfs_headroom

On 20/08/2023 23:06, Qais Yousef wrote:
> We are providing headroom for the utilization to grow until the next
> decision point to pick the next frequency. Give the function a better
> name and give it some documentation. It is not really mapping anything.

Wasn't the original aim to have a counterpart to task scheduler's
fits_capacity(), i.e. implement a frequency tipping point at 80%?

  #define fits_capacity(cap, max) ((cap) * 1280 < (max) * 1024)


(util / max) = 0.8, hence 1.25 for the frequency-invariant case?

https://lkml.kernel.org/r/11678919.CQLTrQTYxG@vostro.rjw.lan

  next_freq = 1.25 * max_freq * util / max

              1,25 *            util  <-- map_util_perf()

[...]

Difference is that EAS deals with `util_cfs` and `capacity` whereas
power (CPUfreq and EM) deals with `util` and `capacity_orig`. And this
is where `capacity pressure` comes in for EAS (or fair.c).

In this regard, I'm not sure why we should rename the function?

> + * This function provides enough headroom to provide adequate performance
> + * assuming the CPU continues to be busy.
> + *
> + * At the moment it is a constant multiplication with 1.25.
> + *
> + * TODO: The headroom should be a function of the delay. 25% is too high
> + * especially on powerful systems. For example, if the delay is 500us, it makes
> + * more sense to give a small headroom as the next decision point is not far
> + * away and will follow the util if it continues to rise. On the other hand if
> + * the delay is 10ms, then we need a bigger headroom so the CPU won't struggle
> + * at a lower frequency if it never goes to idle until then.

I wouldn't add this here since this implementation is not provided.

[...]