[PATCH 0/2] sched/cpufreq: Fix schedutil's boost frequency handling

[PATCH 0/2] sched/cpufreq: Fix schedutil's boost frequency handling

[Sibi Sankar]

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.

This series fixes this by plugging in policy-max into the map_util_freq
equation and allowing cpuinfo max to fallback to a non-boost value when
disabled.

Drivers that rely on the current behaviour (upward bump only) may be
affected; We should handle such cases in the driver side without
breaking core behaviour.

Logs:

# cd /sys/devices/system/cpu/cpufreq/
# ls
boost  policy0  policy12  policy6
# cat boost
0
# cat policy6/scaling_max_freq
4454400
# echo 1 > boost
# cat policy6/scaling_max_freq
4723200
# echo 0 > boost
# cat policy6/scaling_max_freq
4723200

# echo 1 > boost
# cat policy6/stats/time_in_state
355200 36958
4454400 650
4588800 0
4723200 0
#

Logs: With this series

# cd /sys/devices/system/cpu/cpufreq/
# ls
boost  policy0  policy12  policy6
# cat boost
0
# cat policy6/scaling_max_freq
4454400
# echo 1 > boost
# cat policy6/scaling_max_freq
4723200
# echo 0 > policy6/boost
# cat policy6/scaling_max_freq
4454400

# cat policy6/boost
0

# cat policy6/stats/time_in_state
355200 40147
4454400 79
4588800 0
4723200 0

# echo 1 > policy6/boost

# cat policy6/stats/time_in_state
355200 44834
4454400 93
4588800 25
4723200 569

Ananthu C V (1):
  cpufreq: allow cpuinfo max to decrease when boost is disabled

Sibi Sankar (1):
  sched/cpufreq: Update schedutil's DVFS request to reach the boost
    frequencies

 drivers/cpufreq/freq_table.c     |  7 +------
 kernel/sched/cpufreq_schedutil.c | 13 ++++++++++---
 2 files changed, 11 insertions(+), 9 deletions(-)


base-commit: 0f6da28aab51b16762ed82e8fdeaa5042da45b08
-- 
2.34.1

[PATCH 1/2] cpufreq: allow cpuinfo max to decrease when boost is disabled

[Sibi Sankar]

From: Ananthu C V <ananthu.cv@oss.qualcomm.com>

Commit 538b0188da46 ("cpufreq: ACPI: Set cpuinfo.max_freq directly
if max boost is known") guarded cpuinfo max updates to only allow
increases, preserving values set directly by drivers above the freq
table maximum. This prevents cpuinfo max from decreasing on boost
disable, leaving policy max pinned at the boost ceiling.

Remove the guard so cpuinfo max is always derived from the frequency
table scan. Drivers that correctly flag boost entries are unaffected
since the scan already excludes them when boost is off.

Fixes: 538b0188da46 ("cpufreq: ACPI: Set cpuinfo.max_freq directly if max boost is known")
Signed-off-by: Ananthu C V <ananthu.cv@oss.qualcomm.com>
Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
---
 drivers/cpufreq/freq_table.c | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/cpufreq/freq_table.c b/drivers/cpufreq/freq_table.c
index ea994647abc8..791118466ca4 100644
--- a/drivers/cpufreq/freq_table.c
+++ b/drivers/cpufreq/freq_table.c
@@ -50,12 +50,7 @@ int cpufreq_frequency_table_cpuinfo(struct cpufreq_policy *policy)
 	}
 
 	policy->cpuinfo.min_freq = min_freq;
-	/*
-	 * If the driver has set its own cpuinfo.max_freq above max_freq, leave
-	 * it as is.
-	 */
-	if (policy->cpuinfo.max_freq < max_freq)
-		policy->cpuinfo.max_freq = max_freq;
+	policy->cpuinfo.max_freq = max_freq;
 
 	if (min_freq == ~0)
 		return -EINVAL;
-- 
2.34.1

Re: [PATCH 1/2] cpufreq: allow cpuinfo max to decrease when boost is disabled

[Dmitry Baryshkov]

On Thu, Aug 06, 2026 at 10:12:29AM +0530, Sibi Sankar wrote:
> From: Ananthu C V <ananthu.cv@oss.qualcomm.com>
> 
> Commit 538b0188da46 ("cpufreq: ACPI: Set cpuinfo.max_freq directly
> if max boost is known") guarded cpuinfo max updates to only allow
> increases, preserving values set directly by drivers above the freq
> table maximum. This prevents cpuinfo max from decreasing on boost
> disable, leaving policy max pinned at the boost ceiling.

Why is this bad?

> 
> Remove the guard so cpuinfo max is always derived from the frequency
> table scan. Drivers that correctly flag boost entries are unaffected
> since the scan already excludes them when boost is off.
> 
> Fixes: 538b0188da46 ("cpufreq: ACPI: Set cpuinfo.max_freq directly if max boost is known")
> Signed-off-by: Ananthu C V <ananthu.cv@oss.qualcomm.com>
> Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
> ---
>  drivers/cpufreq/freq_table.c | 7 +------
>  1 file changed, 1 insertion(+), 6 deletions(-)
> 

-- 
With best wishes
Dmitry

Re: [PATCH 1/2] cpufreq: allow cpuinfo max to decrease when boost is disabled

[Sibi Sankar]

On 8/6/2026 2:58 PM, Dmitry Baryshkov wrote:
> On Thu, Aug 06, 2026 at 10:12:29AM +0530, Sibi Sankar wrote:
>> From: Ananthu C V <ananthu.cv@oss.qualcomm.com>
>>
>> Commit 538b0188da46 ("cpufreq: ACPI: Set cpuinfo.max_freq directly
>> if max boost is known") guarded cpuinfo max updates to only allow
>> increases, preserving values set directly by drivers above the freq
>> table maximum. This prevents cpuinfo max from decreasing on boost
>> disable, leaving policy max pinned at the boost ceiling.
> Why is this bad?

Copy pasting logs shared from the cover letter:

# cd /sys/devices/system/cpu/cpufreq/
# ls
boost  policy0  policy12  policy6
# cat boost
0
# cat policy6/scaling_max_freq
4454400
# echo 1 > boost
# cat policy6/scaling_max_freq
4723200
# echo 0 > boost
# cat policy6/scaling_max_freq
4723200

Currently disabling boost after enabling it is a NOP,
scaling_max freq in this case would be pinned to turbo.
It will be reachable through various govenors. Also policy
specific boost flag is meaningless unless we have means to
reduce the scaling_max_freq.

>
>> Remove the guard so cpuinfo max is always derived from the frequency
>> table scan. Drivers that correctly flag boost entries are unaffected
>> since the scan already excludes them when boost is off.
>>
>> Fixes: 538b0188da46 ("cpufreq: ACPI: Set cpuinfo.max_freq directly if max boost is known")
>> Signed-off-by: Ananthu C V <ananthu.cv@oss.qualcomm.com>
>> Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
>> ---
>>   drivers/cpufreq/freq_table.c | 7 +------
>>   1 file changed, 1 insertion(+), 6 deletions(-)
>>

Re: [PATCH 1/2] cpufreq: allow cpuinfo max to decrease when boost is disabled

[Dmitry Baryshkov]

On Thu, Aug 06, 2026 at 03:41:45PM +0530, Sibi Sankar wrote:
> 
> On 8/6/2026 2:58 PM, Dmitry Baryshkov wrote:
> > On Thu, Aug 06, 2026 at 10:12:29AM +0530, Sibi Sankar wrote:
> > > From: Ananthu C V <ananthu.cv@oss.qualcomm.com>
> > > 
> > > Commit 538b0188da46 ("cpufreq: ACPI: Set cpuinfo.max_freq directly
> > > if max boost is known") guarded cpuinfo max updates to only allow
> > > increases, preserving values set directly by drivers above the freq
> > > table maximum. This prevents cpuinfo max from decreasing on boost
> > > disable, leaving policy max pinned at the boost ceiling.
> > Why is this bad?
> 
> Copy pasting logs shared from the cover letter:
> 
> # cd /sys/devices/system/cpu/cpufreq/
> # ls
> boost  policy0  policy12  policy6
> # cat boost
> 0
> # cat policy6/scaling_max_freq
> 4454400
> # echo 1 > boost
> # cat policy6/scaling_max_freq
> 4723200
> # echo 0 > boost
> # cat policy6/scaling_max_freq
> 4723200

How is this different from the maximum frequency being unavailable, for
example, because of the thermal pressure?

> 
> Currently disabling boost after enabling it is a NOP,
> scaling_max freq in this case would be pinned to turbo.
> It will be reachable through various govenors. Also policy
> specific boost flag is meaningless unless we have means to
> reduce the scaling_max_freq.
> 
> > 
> > > Remove the guard so cpuinfo max is always derived from the frequency
> > > table scan. Drivers that correctly flag boost entries are unaffected
> > > since the scan already excludes them when boost is off.
> > > 
> > > Fixes: 538b0188da46 ("cpufreq: ACPI: Set cpuinfo.max_freq directly if max boost is known")
> > > Signed-off-by: Ananthu C V <ananthu.cv@oss.qualcomm.com>
> > > Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
> > > ---
> > >   drivers/cpufreq/freq_table.c | 7 +------
> > >   1 file changed, 1 insertion(+), 6 deletions(-)
> > > 

-- 
With best wishes
Dmitry

Re: [PATCH 1/2] cpufreq: allow cpuinfo max to decrease when boost is disabled

[Sibi Sankar]

On 8/6/2026 5:42 PM, Dmitry Baryshkov wrote:
> On Thu, Aug 06, 2026 at 03:41:45PM +0530, Sibi Sankar wrote:
>> On 8/6/2026 2:58 PM, Dmitry Baryshkov wrote:
>>> On Thu, Aug 06, 2026 at 10:12:29AM +0530, Sibi Sankar wrote:
>>>> From: Ananthu C V <ananthu.cv@oss.qualcomm.com>
>>>>
>>>> Commit 538b0188da46 ("cpufreq: ACPI: Set cpuinfo.max_freq directly
>>>> if max boost is known") guarded cpuinfo max updates to only allow
>>>> increases, preserving values set directly by drivers above the freq
>>>> table maximum. This prevents cpuinfo max from decreasing on boost
>>>> disable, leaving policy max pinned at the boost ceiling.
>>> Why is this bad?
>> Copy pasting logs shared from the cover letter:
>>
>> # cd /sys/devices/system/cpu/cpufreq/
>> # ls
>> boost  policy0  policy12  policy6
>> # cat boost
>> 0
>> # cat policy6/scaling_max_freq
>> 4454400
>> # echo 1 > boost
>> # cat policy6/scaling_max_freq
>> 4723200
>> # echo 0 > boost
>> # cat policy6/scaling_max_freq
>> 4723200
> How is this different from the maximum frequency being unavailable, for
> example, because of the thermal pressure?

It's certainly different because the maximum frequency is available in this
case. Consider the following scenario where we use the performance
governor with boost disabled -> enabled -> disabled. The governor would
be voting for the max possible frequency, which is the boost frequency even
when boost is explicitly disabled.

# cat boost
0

# cat policy6/scaling_max_freq
4454400

# echo performance > policy6/scaling_governor
# cat policy6/stats/time_in_state
...
4454400 377
4588800 0
4723200 0

# cat policy6/stats/time_in_state
...
4454400 480
4588800 0
4723200 0

# echo 1 > boost
#
#
# cat policy6/stats/time_in_state
...
4454400 951
4588800 0
4723200 200

# echo 0 > boost

# cat policy6/stats/time_in_state
...
4454400 951
4588800 0
4723200 1048

# cat policy6/stats/time_in_state
...
4454400 951
4588800 0
4723200 1115

Shouldn't this behavior be fixed? The boost flag and per-policy boost flag
have no meaning otherwise.

-Sibi

>
>> Currently disabling boost after enabling it is a NOP,
>> scaling_max freq in this case would be pinned to turbo.
>> It will be reachable through various govenors. Also policy
>> specific boost flag is meaningless unless we have means to
>> reduce the scaling_max_freq.
>>
>>>> Remove the guard so cpuinfo max is always derived from the frequency
>>>> table scan. Drivers that correctly flag boost entries are unaffected
>>>> since the scan already excludes them when boost is off.
>>>>
>>>> Fixes: 538b0188da46 ("cpufreq: ACPI: Set cpuinfo.max_freq directly if max boost is known")
>>>> Signed-off-by: Ananthu C V <ananthu.cv@oss.qualcomm.com>
>>>> Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
>>>> ---
>>>>    drivers/cpufreq/freq_table.c | 7 +------
>>>>    1 file changed, 1 insertion(+), 6 deletions(-)
>>>>

Re: [PATCH 1/2] cpufreq: allow cpuinfo max to decrease when boost is disabled

[Zhongqiu Han]

Hi Sibi and Ananthu,

On 8/6/2026 12:42 PM, Sibi Sankar wrote:
> From: Ananthu C V <ananthu.cv@oss.qualcomm.com>
> 
> Commit 538b0188da46 ("cpufreq: ACPI: Set cpuinfo.max_freq directly
> if max boost is known") guarded cpuinfo max updates to only allow
> increases, preserving values set directly by drivers above the freq
> table maximum. This prevents cpuinfo max from decreasing on boost
> disable, leaving policy max pinned at the boost ceiling.
> 
> Remove the guard so cpuinfo max is always derived from the frequency
> table scan. Drivers that correctly flag boost entries are unaffected
> since the scan already excludes them when boost is off.
> 
> Fixes: 538b0188da46 ("cpufreq: ACPI: Set cpuinfo.max_freq directly if max boost is known")
> Signed-off-by: Ananthu C V <ananthu.cv@oss.qualcomm.com>
> Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
> ---
>   drivers/cpufreq/freq_table.c | 7 +------
>   1 file changed, 1 insertion(+), 6 deletions(-)
> 
> diff --git a/drivers/cpufreq/freq_table.c b/drivers/cpufreq/freq_table.c
> index ea994647abc8..791118466ca4 100644
> --- a/drivers/cpufreq/freq_table.c
> +++ b/drivers/cpufreq/freq_table.c
> @@ -50,12 +50,7 @@ int cpufreq_frequency_table_cpuinfo(struct cpufreq_policy *policy)
>   	}
>   
>   	policy->cpuinfo.min_freq = min_freq;
> -	/*
> -	 * If the driver has set its own cpuinfo.max_freq above max_freq, leave
> -	 * it as is.
> -	 */
> -	if (policy->cpuinfo.max_freq < max_freq)
> -		policy->cpuinfo.max_freq = max_freq;

As I understand it, the guard added by commit 538b0188da46 is
intended for drivers (e.g. acpi-cpufreq and AMD) that may set
cpuinfo.max_freq above the maximum frequency in the frequency table.
Removing it may cause those drivers to lose their boost maximum
frequency.

The regression should instead be related to commit db80ad776cd2
("cpufreq: Remove driver default policy->min/max init"), which removed
the "policy->max = max_freq" initialization that previously allowed
policy->max to track the result of the boost-aware frequency scan.

Please feel free to let me know what you think. Thanks


> +	policy->cpuinfo.max_freq = max_freq;
>   
>   	if (min_freq == ~0)
>   		return -EINVAL;


-- 
Thx and BRs,
Zhongqiu Han

Re: [PATCH 1/2] cpufreq: allow cpuinfo max to decrease when boost is disabled

[Sibi Sankar]

On 8/6/2026 4:52 PM, Zhongqiu Han wrote:
> Hi Sibi and Ananthu,
>
> On 8/6/2026 12:42 PM, Sibi Sankar wrote:
>> From: Ananthu C V <ananthu.cv@oss.qualcomm.com>
>>
>> Commit 538b0188da46 ("cpufreq: ACPI: Set cpuinfo.max_freq directly
>> if max boost is known") guarded cpuinfo max updates to only allow
>> increases, preserving values set directly by drivers above the freq
>> table maximum. This prevents cpuinfo max from decreasing on boost
>> disable, leaving policy max pinned at the boost ceiling.
>>
>> Remove the guard so cpuinfo max is always derived from the frequency
>> table scan. Drivers that correctly flag boost entries are unaffected
>> since the scan already excludes them when boost is off.
>>
>> Fixes: 538b0188da46 ("cpufreq: ACPI: Set cpuinfo.max_freq directly if 
>> max boost is known")
>> Signed-off-by: Ananthu C V <ananthu.cv@oss.qualcomm.com>
>> Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
>> ---
>>   drivers/cpufreq/freq_table.c | 7 +------
>>   1 file changed, 1 insertion(+), 6 deletions(-)
>>
>> diff --git a/drivers/cpufreq/freq_table.c b/drivers/cpufreq/freq_table.c
>> index ea994647abc8..791118466ca4 100644
>> --- a/drivers/cpufreq/freq_table.c
>> +++ b/drivers/cpufreq/freq_table.c
>> @@ -50,12 +50,7 @@ int cpufreq_frequency_table_cpuinfo(struct 
>> cpufreq_policy *policy)
>>       }
>>         policy->cpuinfo.min_freq = min_freq;
>> -    /*
>> -     * If the driver has set its own cpuinfo.max_freq above 
>> max_freq, leave
>> -     * it as is.
>> -     */
>> -    if (policy->cpuinfo.max_freq < max_freq)
>> -        policy->cpuinfo.max_freq = max_freq;
>
> As I understand it, the guard added by commit 538b0188da46 is
> intended for drivers (e.g. acpi-cpufreq and AMD) that may set
> cpuinfo.max_freq above the maximum frequency in the frequency table.
> Removing it may cause those drivers to lose their boost maximum
> frequency.

Yup, we did mention the same in the cover letter.

>
> The regression should instead be related to commit db80ad776cd2
> ("cpufreq: Remove driver default policy->min/max init"), which removed
> the "policy->max = max_freq" initialization that previously allowed
> policy->max to track the result of the boost-aware frequency scan.
>
> Please feel free to let me know what you think. Thanks
>

The commit db80ad776cd2 is unrelated. The problem comes from the
fact that policy_set_boost uses policy->cpuinfo.max_freq in it's
freq_qos_update_request. If we modify it to use a frequency that
adheres to the boost and per-policy boost flag instead might be
the right thing to do here.

>
>> +    policy->cpuinfo.max_freq = max_freq;
>>         if (min_freq == ~0)
>>           return -EINVAL;
>
>

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

[Sibi Sankar]

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 <sibi.sankar@oss.qualcomm.com>
---
 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);
 
 	if (freq == sg_policy->cached_raw_freq && !sg_policy->need_freq_update)
 		return sg_policy->next_freq;
-- 
2.34.1

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

[Christian Loehle]

On 8/6/26 05:42, Sibi Sankar 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 <sibi.sankar@oss.qualcomm.com>
> ---
>  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.

I'm not sure those two statements are compatible with the implementation below?
util / max is expressed in the capacity scale established using ref, multiplying
that ratio by policy->max changes the interpretation of every util value.


> +	 */
> +	freq = map_util_freq(util, max(ref, READ_ONCE(policy->max)), max);

Isn't the underlying problem that schedutil can't handle requests above capacity 1024?

effective_cpu_util() caps util at max, and sugov_effective_cpu_perf() applies
the 25% headroom before clipping the result back to that same value.
Therefore the input here cannot exceed 1024, and mapping it against ref
can never request a frequency above ref.
Using policy->max makes boost reachable, but also stretches the complete frequency range.
For example, with ref = 4454400, policy->max = 4723200, and effective util 640, the request
changes from 2784000 to 2952000.

Making 'boost frequencies' truly compatible with schedutil (or PELT/CAS for that matter)
is a discussion that is yet to be had?
See also
https://lore.kernel.org/lkml/20250626093018.106265-1-dietmar.eggemann@arm.com/

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

[Vincent Guittot]

On Thu, 6 Aug 2026 at 11:02, Christian Loehle <christian.loehle@arm.com> wrote:
>
> On 8/6/26 05:42, Sibi Sankar 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 <sibi.sankar@oss.qualcomm.com>
> > ---
> >  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.
>
> I'm not sure those two statements are compatible with the implementation below?
> util / max is expressed in the capacity scale established using ref, multiplying
> that ratio by policy->max changes the interpretation of every util value.
>
>
> > +      */
> > +     freq = map_util_freq(util, max(ref, READ_ONCE(policy->max)), max);
>
> Isn't the underlying problem that schedutil can't handle requests above capacity 1024?
>
> effective_cpu_util() caps util at max, and sugov_effective_cpu_perf() applies
> the 25% headroom before clipping the result back to that same value.
> Therefore the input here cannot exceed 1024, and mapping it against ref
> can never request a frequency above ref.
> Using policy->max makes boost reachable, but also stretches the complete frequency range.
> For example, with ref = 4454400, policy->max = 4723200, and effective util 640, the request
> changes from 2784000 to 2952000.
>
> Making 'boost frequencies' truly compatible with schedutil (or PELT/CAS for that matter)
> is a discussion that is yet to be had?
> See also
> https://lore.kernel.org/lkml/20250626093018.106265-1-dietmar.eggemann@arm.com/

cpufreq_pressure and freq_qos_update_request could handle the case
where boost freq is used as the ref freq when setting capacity but
disabled. I can't remember if everything was already in place when we
discussed this last time

>

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

[Sibi Sankar]

On 8/6/2026 8:43 PM, Vincent Guittot wrote:
> On Thu, 6 Aug 2026 at 11:02, Christian Loehle <christian.loehle@arm.com> wrote:
>> On 8/6/26 05:42, Sibi Sankar 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 <sibi.sankar@oss.qualcomm.com>
>>> ---
>>>   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.
>> I'm not sure those two statements are compatible with the implementation below?
>> util / max is expressed in the capacity scale established using ref, multiplying
>> that ratio by policy->max changes the interpretation of every util value.
>>
>>
>>> +      */
>>> +     freq = map_util_freq(util, max(ref, READ_ONCE(policy->max)), max);
>> Isn't the underlying problem that schedutil can't handle requests above capacity 1024?
>>
>> effective_cpu_util() caps util at max, and sugov_effective_cpu_perf() applies
>> the 25% headroom before clipping the result back to that same value.
>> Therefore the input here cannot exceed 1024, and mapping it against ref
>> can never request a frequency above ref.
>> Using policy->max makes boost reachable, but also stretches the complete frequency range.
>> For example, with ref = 4454400, policy->max = 4723200, and effective util 640, the request
>> changes from 2784000 to 2952000.
>>
>> Making 'boost frequencies' truly compatible with schedutil (or PELT/CAS for that matter)
>> is a discussion that is yet to be had?
>> See also
>> https://lore.kernel.org/lkml/20250626093018.106265-1-dietmar.eggemann@arm.com/
> cpufreq_pressure and freq_qos_update_request could handle the case
> where boost freq is used as the ref freq when setting capacity but
> disabled. I can't remember if everything was already in place when we
> discussed this last time

Christian/Vincent,
Thanks, will look at how acpi-cpufreq/ccp-cpufreq in the x86 world handle
this and try out some of the suggestions in the link and get back.

>

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

[Vincent Guittot]

On Thu, 6 Aug 2026 at 06:42, Sibi Sankar <sibi.sankar@oss.qualcomm.com> 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 <sibi.sankar@oss.qualcomm.com>
> ---
>  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
>

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

[Sibi Sankar]

On 8/6/2026 8:39 PM, Vincent Guittot wrote:
> On Thu, 6 Aug 2026 at 06:42, Sibi Sankar <sibi.sankar@oss.qualcomm.com> 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 <sibi.sankar@oss.qualcomm.com>
>> ---
>>   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
>>