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

On 8/6/2026 8:39 PM, Vincent Guittot wrote:
> 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.

Thanks for your inputs! Ack, will try out the latter since it appears to 
be the
right way to address this.

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