Messages in this thread | | | Date | Mon, 21 Aug 2023 18:38:25 +0200 | Subject | Re: [PATCH 1/4] sched: cpufreq: Rename map_util_perf to apply_dvfs_headroom | From | 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@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.
[...]
| |