Re: [PATCH 2/2] sched/cpufreq: Update schedutil's DVFS request to reach the boost frequencies

On Thu, 6 Aug 2026 at 06:42, Sibi Sankar <[email protected]> wrote:
>
> capacity_freq_ref, exposed to schedutil via get_capacity_ref_freq(),
> was introduced by commit 9942cb22ea45 ("sched/topology: Add a new
> arch_scale_freq_ref() method") as a fixed anchor that does not move at
> runtime. However, schedutil uses that same fixed anchor as the reference
> plugged into map_util_freq() which saturates exactly at capacity_freq_ref.
>
> As a result, a system with cpufreq boost enabled effectively never runs at
> boost frequencies under schedutil-governed load. Fix this by plugging in
> policy-max into the map_util_freq equation, so that the DVFS requests
> translates to the actual cpufreq driver ceiling.
>
> Signed-off-by: Sibi Sankar <[email protected]>
> ---
>  kernel/sched/cpufreq_schedutil.c | 13 ++++++++++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
> index a1782755efcc..dcefbeaa0702 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -195,10 +195,17 @@ static unsigned int get_next_freq(struct sugov_policy *sg_policy,
>                                   unsigned long util, unsigned long max)
>  {
>         struct cpufreq_policy *policy = sg_policy->policy;
> -       unsigned int freq;
> +       unsigned int freq, ref;
>
> -       freq = get_capacity_ref_freq(policy);
> -       freq = map_util_freq(util, freq, max);
> +       ref = get_capacity_ref_freq(policy);
> +
> +       /*
> +        * That fixed anchor governs how utilization is interpreted, but
> +        * the DVFS request is free to target the current policy ceiling.
> +        * Using ref alone would saturate the util->freq map at ref so
> +        * use policy->max to reach boost frequencies.
> +        */
> +       freq = map_util_freq(util, max(ref, READ_ONCE(policy->max)), max);

But this is wrong because arch_scale_freq_ref is the freq that has
been used when setting the capacity of the cpu and is there to make
sure that the translation between freq <-> capacity is correct and
consistent whatever happens later on the freq table of cpufreq. This
ensures that utilization tracking remains correct vs other CPUS and
prevents or minimizes utilization oscillation, which triggers other
problems

Either we enable the utilization value to go above CPU's capacity when
we transmit it to cpufreq (and above SCHED_CAPACITY_SCALE which could
trigger a number of problem while computing pelt)
Or, you take into account the boost freq when setting cpu's capacity
and associated capacity_freq_ref at boot even if not enabled. With
cpufreq pressure feature and the policy->max (not  cpuinfo_max_freq)
correctly updated with a freq_qos_update_request when boost is
enabled/disabled, the scheduler and pelt should handle that correctly
as we normaly take into account cpufreq_pressure everywhere in
scheduler.

>
>         if (freq == sg_policy->cached_raw_freq && !sg_policy->need_freq_update)
>                 return sg_policy->next_freq;
> --
> 2.34.1
>