[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bc9cd8a3-6bad-3f40-735f-f54b7f3b46b9@arm.com>
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.
[...]
Powered by blists - more mailing lists