cpufreq pressure lowers a CPU's capacity by the ratio between the highest
frequency it may reach and the highest one it can reach right now.
Utilization carries the matching scaling only where the architecture is
frequency invariant; without it a fully busy CPU accumulates the whole
SCHED_CAPACITY_SCALE whatever frequency it runs at.

Reducing capacity on such a system scales one side of the comparison and
not the other, and a fully busy CPU ends up reporting more utilization
than it is credited with being able to run.

This became reachable with commit d2d5c129d07e ("cpufreq: Make
cpufreq_update_pressure() fall back to cpuinfo.max_freq"); before it the
pressure was always zero there. Whether that matters depends on frequency
invariance rather than on the fallback itself: a system that has it scales
both sides and is unaffected, while a system that does not scales only the
capacity.

Fixes: d2d5c129d07e ("cpufreq: Make cpufreq_update_pressure() fall back to cpuinfo.max_freq")
Signed-off-by: Jianyong Wu <wujianyong@hygon.cn>
---
 kernel/sched/fair.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index c19a025d8d68..a163e00c9882 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5854,10 +5854,17 @@ static inline void util_est_dequeue(struct cfs_rq *cfs_rq,
 static inline unsigned long get_actual_cpu_capacity(int cpu)
 {
 	unsigned long capacity = arch_scale_cpu_capacity(cpu);
+	unsigned long pressure = hw_load_avg(cpu_rq(cpu));
 
-	capacity -= max(hw_load_avg(cpu_rq(cpu)), cpufreq_get_pressure(cpu));
+	/*
+	 * Utilization only follows frequency where the architecture is
+	 * frequency invariant. Elsewhere, lowering the capacity would
+	 * scale one side of the comparison and not the other.
+	 */
+	if (arch_scale_freq_invariant())
+		pressure = max(pressure, cpufreq_get_pressure(cpu));
 
-	return capacity;
+	return capacity - pressure;
 }
 
 static inline int util_fits_cpu(unsigned long util,
-- 
2.34.1

On 8/21/2026 3:39 PM, Jianyong Wu wrote:
> cpufreq pressure lowers a CPU's capacity by the ratio between the highest
> frequency it may reach and the highest one it can reach right now.
> Utilization carries the matching scaling only where the architecture is
> frequency invariant; without it a fully busy CPU accumulates the whole
> SCHED_CAPACITY_SCALE whatever frequency it runs at.

Given how PELT works, anything that is always-running without idle time 
under PELT will reach 1024 eventually regardless of invariance.

> Reducing capacity on such a system scales one side of the comparison and
> not the other, and a fully busy CPU ends up reporting more utilization
> than it is credited with being able to run.

Sorry I didn't quite catch what 'comparison' means, and it's fairly 
normal for task and CPU utilization to exceed capacity w/ or w/o 
invariance. We just manually cap it to CPU capacity in a few places. 
Could you be more specific on what the problem is?

> This became reachable with commit d2d5c129d07e ("cpufreq: Make
> cpufreq_update_pressure() fall back to cpuinfo.max_freq"); before it the
> pressure was always zero there. Whether that matters depends on frequency
> invariance rather than on the fallback itself: a system that has it scales
> both sides and is unaffected, while a system that does not scales only the
> capacity.
> 
> Fixes: d2d5c129d07e ("cpufreq: Make cpufreq_update_pressure() fall back to cpuinfo.max_freq")
> Signed-off-by: Jianyong Wu <wujianyong@hygon.cn>
> ---
>   kernel/sched/fair.c | 11 +++++++++--
>   1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index c19a025d8d68..a163e00c9882 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -5854,10 +5854,17 @@ static inline void util_est_dequeue(struct cfs_rq *cfs_rq,
>   static inline unsigned long get_actual_cpu_capacity(int cpu)
>   {
>   	unsigned long capacity = arch_scale_cpu_capacity(cpu);
> +	unsigned long pressure = hw_load_avg(cpu_rq(cpu));
>   
> -	capacity -= max(hw_load_avg(cpu_rq(cpu)), cpufreq_get_pressure(cpu));
> +	/*
> +	 * Utilization only follows frequency where the architecture is
> +	 * frequency invariant. Elsewhere, lowering the capacity would
> +	 * scale one side of the comparison and not the other.
> +	 */
> +	if (arch_scale_freq_invariant())
> +		pressure = max(pressure, cpufreq_get_pressure(cpu));
>   
> -	return capacity;
> +	return capacity - pressure;
>   }
>   
>   static inline int util_fits_cpu(unsigned long util,

Hi Vincent, Hongyan,

Thanks for your comments.

My original commit message did not clearly describe the concrete issue
being fixed, and its explanation based on frequency invariance was not
correct. After looking into this further, I found that the issue I
observed has a different cause: the cpuinfo.max_freq fallback added by
d2d5c129d07e ("cpufreq: Make cpufreq_update_pressure() fall back to
cpuinfo.max_freq").

The commit message says:

  However, in the absence of arch_scale_freq_ref(), it is reasonable
  to assume that cpuinfo.max_freq is the maximum sustainable frequency
  for the given cpufreq policy.

That assumption does not always hold.

On an x86 server using acpi-cpufreq, cpuinfo.max_freq includes the
autonomous boost frequency, while policy->max is resolved to the
highest selectable _PSS state. With boost enabled and policy->max
unchanged at that state, the measured CPU frequency can still exceed
policy->max. Thus, policy->max does not represent an effective hardware
maximum-frequency cap in this case.

Nevertheless, the cpuinfo.max_freq fallback makes
cpufreq_update_pressure() calculate positive pressure for every policy,
although no effective maximum-frequency restriction has been applied.

The underlying issue is that cpuinfo.max_freq is the maximum possible
operating frequency and may include an autonomous boost frequency,
whereas policy->max may represent the highest selectable _PSS state.
Consequently, policy->max < cpuinfo.max_freq does not necessarily mean
that the available CPU capacity has been capped.


Therefore, this patch checks the wrong condition and is not the right fix. I will drop it.

Instead, I am investigating a fix for the reference-frequency fallback
in the cpufreq subsystem. One possible approach is to use the highest
non-boost frequency-table entry when arch_scale_freq_ref() is
unavailable, and only fall back to cpuinfo.max_freq for drivers without
such an entry.

Does that approach sound reasonable?

Thanks
Jianyong

> 

On Mon, 24 Aug 2026 at 15:06, Jianyong Wu <jianyong.wu@outlook.com> wrote:
>
> Hi Vincent, Hongyan,
>
> Thanks for your comments.
>
> My original commit message did not clearly describe the concrete issue
> being fixed, and its explanation based on frequency invariance was not
> correct. After looking into this further, I found that the issue I
> observed has a different cause: the cpuinfo.max_freq fallback added by
> d2d5c129d07e ("cpufreq: Make cpufreq_update_pressure() fall back to
> cpuinfo.max_freq").
>
> The commit message says:
>
>   However, in the absence of arch_scale_freq_ref(), it is reasonable
>   to assume that cpuinfo.max_freq is the maximum sustainable frequency
>   for the given cpufreq policy.
>
> That assumption does not always hold.
>
> On an x86 server using acpi-cpufreq, cpuinfo.max_freq includes the
> autonomous boost frequency, while policy->max is resolved to the
> highest selectable _PSS state. With boost enabled and policy->max
> unchanged at that state, the measured CPU frequency can still exceed
> policy->max. Thus, policy->max does not represent an effective hardware
> maximum-frequency cap in this case.
>
> Nevertheless, the cpuinfo.max_freq fallback makes
> cpufreq_update_pressure() calculate positive pressure for every policy,
> although no effective maximum-frequency restriction has been applied.
>
> The underlying issue is that cpuinfo.max_freq is the maximum possible
> operating frequency and may include an autonomous boost frequency,
> whereas policy->max may represent the highest selectable _PSS state.
> Consequently, policy->max < cpuinfo.max_freq does not necessarily mean
> that the available CPU capacity has been capped.

IIUC, cpuinfo.max_freq == boost freq and policy->max reflects the
correct highest frequency reachable by the CPU when boost is disabled
so the cpufreq_pressure is correct. But your policy->max is not
updated when boot is enable and doesn't reflect the highest freq
reachable by the CPU.

>
>
> Therefore, this patch checks the wrong condition and is not the right fix. I will drop it.
>
> Instead, I am investigating a fix for the reference-frequency fallback
> in the cpufreq subsystem. One possible approach is to use the highest
> non-boost frequency-table entry when arch_scale_freq_ref() is
> unavailable, and only fall back to cpuinfo.max_freq for drivers without
> such an entry.
>
> Does that approach sound reasonable?
>
> Thanks
> Jianyong
>
> >
>

On 8/24/2026 9:06 PM, Jianyong Wu wrote:
> Hi Vincent, Hongyan,
> 
> Thanks for your comments.
> 
> My original commit message did not clearly describe the concrete issue
> being fixed, and its explanation based on frequency invariance was not
> correct. After looking into this further, I found that the issue I
> observed has a different cause: the cpuinfo.max_freq fallback added by
> d2d5c129d07e ("cpufreq: Make cpufreq_update_pressure() fall back to
> cpuinfo.max_freq").
> 
> The commit message says:
> 
>    However, in the absence of arch_scale_freq_ref(), it is reasonable
>    to assume that cpuinfo.max_freq is the maximum sustainable frequency
>    for the given cpufreq policy.
> 
> That assumption does not always hold.
> 
> On an x86 server using acpi-cpufreq, cpuinfo.max_freq includes the
> autonomous boost frequency, while policy->max is resolved to the
> highest selectable _PSS state. With boost enabled and policy->max
> unchanged at that state, the measured CPU frequency can still exceed
> policy->max. Thus, policy->max does not represent an effective hardware
> maximum-frequency cap in this case.
> 
> Nevertheless, the cpuinfo.max_freq fallback makes
> cpufreq_update_pressure() calculate positive pressure for every policy,
> although no effective maximum-frequency restriction has been applied.
> 
> The underlying issue is that cpuinfo.max_freq is the maximum possible
> operating frequency and may include an autonomous boost frequency,
> whereas policy->max may represent the highest selectable _PSS state.
> Consequently, policy->max < cpuinfo.max_freq does not necessarily mean
> that the available CPU capacity has been capped.
> 
> 
> Therefore, this patch checks the wrong condition and is not the right fix. I will drop it.
> 
> Instead, I am investigating a fix for the reference-frequency fallback
> in the cpufreq subsystem. One possible approach is to use the highest
> non-boost frequency-table entry when arch_scale_freq_ref() is
> unavailable, and only fall back to cpuinfo.max_freq for drivers without
> such an entry.

I see. So basically on your system, cpuinfo.max_freq includes boost 
frequencies whereas policy->max doesn't, so the policy->max < 
cpuinfo.max_freq arithmetic comparison gives you 'pressure' even without 
any actual pressure in your system. You might want to re-phrase the 
problem better as it took me quite a while to understand it.

So this is not frequency-invariance-related. This basically boils down 
to the definition of different policy->fields, which might be better 
commented by people working often with boost frequencies.

> Does that approach sound reasonable?
> 
> Thanks
> Jianyong

On Fri, 21 Aug 2026 at 09:43, Jianyong Wu <wujianyong@hygon.cn> wrote:
>
> cpufreq pressure lowers a CPU's capacity by the ratio between the highest
> frequency it may reach and the highest one it can reach right now.
> Utilization carries the matching scaling only where the architecture is
> frequency invariant; without it a fully busy CPU accumulates the whole
> SCHED_CAPACITY_SCALE whatever frequency it runs at.
>
> Reducing capacity on such a system scales one side of the comparison and
> not the other, and a fully busy CPU ends up reporting more utilization
> than it is credited with being able to run.

Even with frequency invariance, utilization can exceed capacity, only
the time to reach it will change.

What issue do you try to fix?

>
> This became reachable with commit d2d5c129d07e ("cpufreq: Make
> cpufreq_update_pressure() fall back to cpuinfo.max_freq"); before it the
> pressure was always zero there. Whether that matters depends on frequency
> invariance rather than on the fallback itself: a system that has it scales
> both sides and is unaffected, while a system that does not scales only the
> capacity.
>
> Fixes: d2d5c129d07e ("cpufreq: Make cpufreq_update_pressure() fall back to cpuinfo.max_freq")
> Signed-off-by: Jianyong Wu <wujianyong@hygon.cn>
> ---
>  kernel/sched/fair.c | 11 +++++++++--
>  1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index c19a025d8d68..a163e00c9882 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -5854,10 +5854,17 @@ static inline void util_est_dequeue(struct cfs_rq *cfs_rq,
>  static inline unsigned long get_actual_cpu_capacity(int cpu)
>  {
>         unsigned long capacity = arch_scale_cpu_capacity(cpu);
> +       unsigned long pressure = hw_load_avg(cpu_rq(cpu));
>
> -       capacity -= max(hw_load_avg(cpu_rq(cpu)), cpufreq_get_pressure(cpu));
> +       /*
> +        * Utilization only follows frequency where the architecture is
> +        * frequency invariant. Elsewhere, lowering the capacity would
> +        * scale one side of the comparison and not the other.
> +        */
> +       if (arch_scale_freq_invariant())
> +               pressure = max(pressure, cpufreq_get_pressure(cpu));
>
> -       return capacity;
> +       return capacity - pressure;
>  }
>
>  static inline int util_fits_cpu(unsigned long util,
> --
> 2.34.1
>
>