Re: [PATCH 1/4] sched: cpufreq: Rename map_util_perf to apply_dvfs_headroom

[Dietmar Eggemann]

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@xxxxxxxxxxxxxx

  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.

[...]