[PATCH] sched/fair: Only apply cpufreq pressure where frequency is invariant

[PATCH] sched/fair: Only apply cpufreq pressure where frequency is invariant

[Jianyong Wu]

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

Re: [PATCH] sched/fair: Only apply cpufreq pressure where frequency is invariant

[Vincent Guittot]

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
>
>

Re: [PATCH] sched/fair: Only apply cpufreq pressure where frequency is invariant

[Hongyan Xia]

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,

Re: [PATCH] sched/fair: Only apply cpufreq pressure where frequency is invariant

[Jianyong Wu]

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

> 

Re: [PATCH] sched/fair: Only apply cpufreq pressure where frequency is invariant

[Hongyan Xia]

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

Re: [PATCH] sched/fair: Only apply cpufreq pressure where frequency is invariant

[jong wu]

在 2026/8/25 15:40, Hongyan Xia 写道:
> 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.
> 

Right, that's exactly the point, and sorry for the confusing wording.
I will re-phrase the problem statement in the next version.

> 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.
> 

Agreed, this is not frequency-invariance related. I have followed up on
the cpufreq side in a separate reply to Vincent, proposing to let
cpufreq_update_pressure() tell whether policy->max is an actual cap by
checking whether the boost frequency lives outside the frequency table.
Input from the cpufreq folks would be very welcome.

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

Re: [PATCH] sched/fair: Only apply cpufreq pressure where frequency is invariant

[Vincent Guittot]

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
>
> >
>

Re: [PATCH] sched/fair: Only apply cpufreq pressure where frequency is invariant

[jong wu]

在 2026/8/25 21:05, Vincent Guittot 写道:
> 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.
> 

Exactly. I think the root cause is that policy->max has different
semantics across cpufreq drivers. On Intel and most AMD machines it is
the maximum attainable frequency, i.e. the boost frequency when boost
is enabled. For acpi-cpufreq, however, policy->max is resolved from the
ACPI _PSS table, which does not contain the boost frequency.

So I think we should give cpufreq_update_pressure() enough information
to decide whether the CPU is really capped. For example, add to struct
cpufreq_policy:

   - boost_freqs_outside_table: the boost frequency is not present in
     the frequency table;
   - table_max: the highest frequency inside the frequency table.

Then the "not capped" case can be detected with:

       if (policy->boost_freqs_outside_table &&
           policy->boost_enabled &&
           policy->max == policy->table_max)
               capped_freq = max_freq;

Once the CPU is known not to be capped, cpufreq_update_pressure() can
use cpuinfo.max_freq as capped_freq instead of policy->max.

WDYT?

Thanks
Jianyong




>>
>>
>> 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
>>
>>>
>>

Re: [PATCH] sched/fair: Only apply cpufreq pressure where frequency is invariant

[Hongyan Xia]

On 9/2/2026 4:49 PM, jong wu wrote:
> 在 2026/8/25 21:05, Vincent Guittot 写道:
>> 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.
>>
> 
> Exactly. I think the root cause is that policy->max has different
> semantics across cpufreq drivers. On Intel and most AMD machines it is
> the maximum attainable frequency, i.e. the boost frequency when boost
> is enabled. For acpi-cpufreq, however, policy->max is resolved from the
> ACPI _PSS table, which does not contain the boost frequency.

Proper solutions aside, I vaguely remember investigating scheduler 
issues on a Ryzen 7840U. That has acpi-cpufreq with only 3 OPPs. Boost 
frequencies are not included in those 3 and are much higher than the 
ACPI OPPs. I certainly managed to disable pstate and switched to 
acpi-cpufreq on it. I wonder if you can reproduce such issues on such a 
machine. Maybe this is a broader issue than we realize.

> [...]

Re: [PATCH] sched/fair: Only apply cpufreq pressure where frequency is invariant

[jong wu]

在 2026/9/2 17:37, Hongyan Xia 写道:
> On 9/2/2026 4:49 PM, jong wu wrote:
>> 在 2026/8/25 21:05, Vincent Guittot 写道:
>>> 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.
>>>
>>
>> Exactly. I think the root cause is that policy->max has different
>> semantics across cpufreq drivers. On Intel and most AMD machines it is
>> the maximum attainable frequency, i.e. the boost frequency when boost
>> is enabled. For acpi-cpufreq, however, policy->max is resolved from the
>> ACPI _PSS table, which does not contain the boost frequency.
> 
> Proper solutions aside, I vaguely remember investigating scheduler
> issues on a Ryzen 7840U. That has acpi-cpufreq with only 3 OPPs. Boost
> frequencies are not included in those 3 and are much higher than the
> ACPI OPPs. I certainly managed to disable pstate and switched to
> acpi-cpufreq on it. I wonder if you can reproduce such issues on such a
> machine. Maybe this is a broader issue than we realize.

That may well be the case, but so far I have only observed it on my own
machine, so I would rather not claim more than that yet.

My current understanding is that the trigger would be the driver rather
than the vendor: if a system runs acpi-cpufreq and its boost frequency
is not present in the _PSS table, the same reasoning should apply. The
7840U you describe -- 3 OPPs, boost well above the highest one -- looks
like it could fit that shape, but that remains a guess until it is
actually measured.

I do not have a 7840U at hand. I will try to reproduce it on an Intel
or AMD box by forcing acpi-cpufreq (intel_pstate=disable /
amd_pstate=disable), then comparing the measured frequency against
policy->max with boost enabled and checking whether a non-zero cpufreq
pressure shows up while the system is unconstrained. I will report back
with the numbers once I have them.

Thanks
Jianyong

Thanks
Jianyong>
>> [...]

Re: [PATCH] sched/fair: Only apply cpufreq pressure where frequency is invariant

[Hongyan Xia]

On 9/3/2026 10:04 AM, jong wu wrote:
> 在 2026/9/2 17:37, Hongyan Xia 写道:
>> On 9/2/2026 4:49 PM, jong wu wrote:
>>> 在 2026/8/25 21:05, Vincent Guittot 写道:
>>>> 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.
>>>>
>>>
>>> Exactly. I think the root cause is that policy->max has different
>>> semantics across cpufreq drivers. On Intel and most AMD machines it is
>>> the maximum attainable frequency, i.e. the boost frequency when boost
>>> is enabled. For acpi-cpufreq, however, policy->max is resolved from the
>>> ACPI _PSS table, which does not contain the boost frequency.
>>
>> Proper solutions aside, I vaguely remember investigating scheduler
>> issues on a Ryzen 7840U. That has acpi-cpufreq with only 3 OPPs. Boost
>> frequencies are not included in those 3 and are much higher than the
>> ACPI OPPs. I certainly managed to disable pstate and switched to
>> acpi-cpufreq on it. I wonder if you can reproduce such issues on such a
>> machine. Maybe this is a broader issue than we realize.
> 
> That may well be the case, but so far I have only observed it on my own
> machine, so I would rather not claim more than that yet.
> 
> My current understanding is that the trigger would be the driver rather
> than the vendor: if a system runs acpi-cpufreq and its boost frequency
> is not present in the _PSS table, the same reasoning should apply. The
> 7840U you describe -- 3 OPPs, boost well above the highest one -- looks
> like it could fit that shape, but that remains a guess until it is
> actually measured.
> 
> I do not have a 7840U at hand. I will try to reproduce it on an Intel
> or AMD box by forcing acpi-cpufreq (intel_pstate=disable /
> amd_pstate=disable), then comparing the measured frequency against
> policy->max with boost enabled and checking whether a non-zero cpufreq
> pressure shows up while the system is unconstrained. I will report back
> with the numbers once I have them.

I managed to reproduce the problem on an AMD 5900X. I added trace_printk 
outputs on cpufreq pressure updates. Under AMD pstate with boost 
frequencies I get:

[006] .....    34.096492: cpufreq_set_policy: CPU 1 has max_freq 
4683471, max 4683471

You can see policy->cpuinfo.max_freq and policy->max are the same.

If I force disable pstate and use ACPI OPPs with schedutil but still 
with boost frequencies, I get:

[003] .....     4.697753: cpufreq_set_policy: CPU 1 has max_freq 
4680714, max 3300000

So you can see policy->max includes no boost frequencies (3300000 is the 
highest OPP) and will trigger policy->max < policy->cpuinfo.max_freq, 
hence applying pressure when there is actually no pressure.

The conclusion is that yes, this is a wider problem than we realize. I 
suspect this might also be present in Intel CPUs with ACPI cpufreq.

Re: [PATCH] sched/fair: Only apply cpufreq pressure where frequency is invariant

[K Prateek Nayak]

Hello folks,

On 9/7/2026 8:02 AM, Hongyan Xia wrote:
> On 9/3/2026 10:04 AM, jong wu wrote:
>> 在 2026/9/2 17:37, Hongyan Xia 写道:
>>> On 9/2/2026 4:49 PM, jong wu wrote:
>>>> 在 2026/8/25 21:05, Vincent Guittot 写道:
>>>>> 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.
>>>>>
>>>>
>>>> Exactly. I think the root cause is that policy->max has different
>>>> semantics across cpufreq drivers. On Intel and most AMD machines it is
>>>> the maximum attainable frequency, i.e. the boost frequency when boost
>>>> is enabled. For acpi-cpufreq, however, policy->max is resolved from the
>>>> ACPI _PSS table, which does not contain the boost frequency.
>>>
>>> Proper solutions aside, I vaguely remember investigating scheduler
>>> issues on a Ryzen 7840U. That has acpi-cpufreq with only 3 OPPs. Boost
>>> frequencies are not included in those 3 and are much higher than the
>>> ACPI OPPs. I certainly managed to disable pstate and switched to
>>> acpi-cpufreq on it. I wonder if you can reproduce such issues on such a
>>> machine. Maybe this is a broader issue than we realize.
>>
>> That may well be the case, but so far I have only observed it on my own
>> machine, so I would rather not claim more than that yet.
>>
>> My current understanding is that the trigger would be the driver rather
>> than the vendor: if a system runs acpi-cpufreq and its boost frequency
>> is not present in the _PSS table, the same reasoning should apply. The
>> 7840U you describe -- 3 OPPs, boost well above the highest one -- looks
>> like it could fit that shape, but that remains a guess until it is
>> actually measured.
>>
>> I do not have a 7840U at hand. I will try to reproduce it on an Intel
>> or AMD box by forcing acpi-cpufreq (intel_pstate=disable /
>> amd_pstate=disable), then comparing the measured frequency against
>> policy->max with boost enabled and checking whether a non-zero cpufreq
>> pressure shows up while the system is unconstrained. I will report back
>> with the numbers once I have them.
> 
> I managed to reproduce the problem on an AMD 5900X. I added trace_printk 
> outputs on cpufreq pressure updates. Under AMD pstate with boost 
> frequencies I get:
> 
> [006] .....    34.096492: cpufreq_set_policy: CPU 1 has max_freq 
> 4683471, max 4683471
> 
> You can see policy->cpuinfo.max_freq and policy->max are the same.
> 
> If I force disable pstate and use ACPI OPPs with schedutil but still 
> with boost frequencies, I get:
> 
> [003] .....     4.697753: cpufreq_set_policy: CPU 1 has max_freq 
> 4680714, max 3300000
> 
> So you can see policy->max includes no boost frequencies (3300000 is the 
> highest OPP) and will trigger policy->max < policy->cpuinfo.max_freq, 
> hence applying pressure when there is actually no pressure.
> 
> The conclusion is that yes, this is a wider problem than we realize. I 
> suspect this might also be present in Intel CPUs with ACPI cpufreq.

So, I've been trying to understand these bits and looking at
cpufreq_policy_init_qos(), the "policy->cpuinfo.max_freq" should be the
frequency including the boost range but I see cpufreq_update_pressure()
and it says:

    max_freq = arch_scale_freq_ref(cpu);
    if (!max_freq)
        max_freq = policy->cpuinfo.max_freq;

    capped_freq = policy->max;

    /*
     * Handle properly the boost frequencies, which should simply clean
     * the cpufreq pressure value.
     */
    if (max_freq <= capped_freq) {
        ...
    }


Looking at this, I feel "policy->cpuinfo.max_freq" should not include
the boost frequency, or x86 should implement a arch_scale_freq_ref()
to know when boost is enabled vs disabled.

If cpufreq_update_pressure() indeed has to disregard boost frequency,
and anything above P0 is not considered as pressure, we can simply
do:

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index b898b6544069..068e6d6e15a1 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -2586,8 +2586,11 @@ static void cpufreq_update_pressure(struct cpufreq_policy *policy)
 
 	cpu = cpumask_first(policy->related_cpus);
 	max_freq = arch_scale_freq_ref(cpu);
-	if (!max_freq)
-		max_freq = policy->cpuinfo.max_freq;
+	if (!max_freq) {
+		max_freq = __resolve_freq(policy, policy->cpuinfo.max_freq,
+					  policy->max, policy->min,
+					  CPUFREQ_RELATION_H);
+	}
 
 	capped_freq = policy->max;
 
---

__resolve_freq() will cap "policy->cpuinfo.max_freq" based on the freq_table
entries if it exists (acpi-cpufreq), or otherwise return
"policy->cpuinfo.max_freq" as is for drivers that uses CPPC based scaling
(amd-pstate, intel_pstate).

Thoughts? 

-- 
Thanks and Regards,
Prateek

Re: [PATCH] sched/fair: Only apply cpufreq pressure where frequency is invariant

[K Prateek Nayak]

On 9/7/2026 1:37 PM, K Prateek Nayak wrote:
> So, I've been trying to understand these bits and looking at
> cpufreq_policy_init_qos(), the "policy->cpuinfo.max_freq" should be the
> frequency including the boost range but I see cpufreq_update_pressure()
> and it says:
> 
>     max_freq = arch_scale_freq_ref(cpu);
>     if (!max_freq)
>         max_freq = policy->cpuinfo.max_freq;
> 
>     capped_freq = policy->max;
> 
>     /*
>      * Handle properly the boost frequencies, which should simply clean
>      * the cpufreq pressure value.
>      */
>     if (max_freq <= capped_freq) {
>         ...
>     }
> 
> 
> Looking at this, I feel "policy->cpuinfo.max_freq" should not include
> the boost frequency, or x86 should implement a arch_scale_freq_ref()
> to know when boost is enabled vs disabled.
> 
> If cpufreq_update_pressure() indeed has to disregard boost frequency,
> and anything above P0 is not considered as pressure, we can simply
> do:
> 
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index b898b6544069..068e6d6e15a1 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -2586,8 +2586,11 @@ static void cpufreq_update_pressure(struct cpufreq_policy *policy)
>  
>  	cpu = cpumask_first(policy->related_cpus);
>  	max_freq = arch_scale_freq_ref(cpu);
> -	if (!max_freq)
> -		max_freq = policy->cpuinfo.max_freq;
> +	if (!max_freq) {
> +		max_freq = __resolve_freq(policy, policy->cpuinfo.max_freq,
> +					  policy->max, policy->min,

My bad, that should have been other way around and use the cpuinfo
fields to prevent capping based on policy limits. Updated diff:

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index b898b6544069..97f4a3ba5107 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -2586,8 +2586,11 @@ static void cpufreq_update_pressure(struct cpufreq_policy *policy)
 
 	cpu = cpumask_first(policy->related_cpus);
 	max_freq = arch_scale_freq_ref(cpu);
-	if (!max_freq)
-		max_freq = policy->cpuinfo.max_freq;
+	if (!max_freq) {
+		max_freq = __resolve_freq(policy, policy->cpuinfo.max_freq,
+					  policy->cpuinfo.min_freq, policy->cpuinfo.max_freq,
+					  CPUFREQ_RELATION_H);
+	}
 
 	capped_freq = policy->max;
 
---

> +					  CPUFREQ_RELATION_H);
> +	}
>  
>  	capped_freq = policy->max;
>  
> ---
> 
> __resolve_freq() will cap "policy->cpuinfo.max_freq" based on the freq_table
> entries if it exists (acpi-cpufreq), or otherwise return
> "policy->cpuinfo.max_freq" as is for drivers that uses CPPC based scaling
> (amd-pstate, intel_pstate).
> 
> Thoughts? 
> 

-- 
Thanks and Regards,
Prateek

Re: [PATCH] sched/fair: Only apply cpufreq pressure where frequency is invariant

[jong wu]

在 2026/9/7 16:37, K Prateek Nayak 写道:
> On 9/7/2026 1:37 PM, K Prateek Nayak wrote:
>> So, I've been trying to understand these bits and looking at
>> cpufreq_policy_init_qos(), the "policy->cpuinfo.max_freq" should be the
>> frequency including the boost range but I see cpufreq_update_pressure()
>> and it says:
>>
>>      max_freq = arch_scale_freq_ref(cpu);
>>      if (!max_freq)
>>          max_freq = policy->cpuinfo.max_freq;
>>
>>      capped_freq = policy->max;
>>
>>      /*
>>       * Handle properly the boost frequencies, which should simply clean
>>       * the cpufreq pressure value.
>>       */
>>      if (max_freq <= capped_freq) {
>>          ...
>>      }
>>
>>
>> Looking at this, I feel "policy->cpuinfo.max_freq" should not include
>> the boost frequency, or x86 should implement a arch_scale_freq_ref()
>> to know when boost is enabled vs disabled.
>>
>> If cpufreq_update_pressure() indeed has to disregard boost frequency,
>> and anything above P0 is not considered as pressure, we can simply
>> do:
>>
>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
>> index b898b6544069..068e6d6e15a1 100644
>> --- a/drivers/cpufreq/cpufreq.c
>> +++ b/drivers/cpufreq/cpufreq.c
>> @@ -2586,8 +2586,11 @@ static void cpufreq_update_pressure(struct cpufreq_policy *policy)
>>   
>>   	cpu = cpumask_first(policy->related_cpus);
>>   	max_freq = arch_scale_freq_ref(cpu);
>> -	if (!max_freq)
>> -		max_freq = policy->cpuinfo.max_freq;
>> +	if (!max_freq) {
>> +		max_freq = __resolve_freq(policy, policy->cpuinfo.max_freq,
>> +					  policy->max, policy->min,
> 
> My bad, that should have been other way around and use the cpuinfo
> fields to prevent capping based on policy limits. Updated diff:
> 
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index b898b6544069..97f4a3ba5107 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -2586,8 +2586,11 @@ static void cpufreq_update_pressure(struct cpufreq_policy *policy)
>   
>   	cpu = cpumask_first(policy->related_cpus);
>   	max_freq = arch_scale_freq_ref(cpu);
> -	if (!max_freq)
> -		max_freq = policy->cpuinfo.max_freq;
> +	if (!max_freq) {
> +		max_freq = __resolve_freq(policy, policy->cpuinfo.max_freq,
> +					  policy->cpuinfo.min_freq, policy->cpuinfo.max_freq,
> +					  CPUFREQ_RELATION_H);
> +	}
>   
>   	capped_freq = policy->max;
>   
> ---
> 
>> +					  CPUFREQ_RELATION_H);
>> +	}
>>   
>>   	capped_freq = policy->max;
>>   
>> ---
>>
>> __resolve_freq() will cap "policy->cpuinfo.max_freq" based on the freq_table
>> entries if it exists (acpi-cpufreq), or otherwise return
>> "policy->cpuinfo.max_freq" as is for drivers that uses CPPC based scaling
>> (amd-pstate, intel_pstate).
>>
>> Thoughts?
>>
I think this is the right way to resolve the issue.  I had written a
patch for it as well, but it is more complex than yours, so I have made
a small change on top of your version instead.  On my machine, where
cpuinfo_max_freq (3100000) sits above the highest _PSS entry (2700000),
the CPU capacity is back to 1024 with it applied.  I will add a
Suggested-by: for you since the approach is yours - if you would rather
post it under your own authorship, say the word and I will stay out of
the way.

Thanks
Jianyong

> 

Re: [PATCH] sched/fair: Only apply cpufreq pressure where frequency is invariant

[Hongyan Xia]

On 9/7/2026 4:37 PM, K Prateek Nayak wrote:
> On 9/7/2026 1:37 PM, K Prateek Nayak wrote:
>> So, I've been trying to understand these bits and looking at
>> cpufreq_policy_init_qos(), the "policy->cpuinfo.max_freq" should be the
>> frequency including the boost range but I see cpufreq_update_pressure()
>> and it says:
>>
>>      max_freq = arch_scale_freq_ref(cpu);
>>      if (!max_freq)
>>          max_freq = policy->cpuinfo.max_freq;
>>
>>      capped_freq = policy->max;
>>
>>      /*
>>       * Handle properly the boost frequencies, which should simply clean
>>       * the cpufreq pressure value.
>>       */
>>      if (max_freq <= capped_freq) {
>>          ...
>>      }
>>
>>
>> Looking at this, I feel "policy->cpuinfo.max_freq" should not include
>> the boost frequency, or x86 should implement a arch_scale_freq_ref()
>> to know when boost is enabled vs disabled.
>>
>> If cpufreq_update_pressure() indeed has to disregard boost frequency,
>> and anything above P0 is not considered as pressure, we can simply
>> do:
>>
>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
>> index b898b6544069..068e6d6e15a1 100644
>> --- a/drivers/cpufreq/cpufreq.c
>> +++ b/drivers/cpufreq/cpufreq.c
>> @@ -2586,8 +2586,11 @@ static void cpufreq_update_pressure(struct cpufreq_policy *policy)
>>   
>>   	cpu = cpumask_first(policy->related_cpus);
>>   	max_freq = arch_scale_freq_ref(cpu);
>> -	if (!max_freq)
>> -		max_freq = policy->cpuinfo.max_freq;
>> +	if (!max_freq) {
>> +		max_freq = __resolve_freq(policy, policy->cpuinfo.max_freq,
>> +					  policy->max, policy->min,
> 
> My bad, that should have been other way around and use the cpuinfo
> fields to prevent capping based on policy limits. Updated diff:
> 
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index b898b6544069..97f4a3ba5107 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -2586,8 +2586,11 @@ static void cpufreq_update_pressure(struct cpufreq_policy *policy)
>   
>   	cpu = cpumask_first(policy->related_cpus);
>   	max_freq = arch_scale_freq_ref(cpu);
> -	if (!max_freq)
> -		max_freq = policy->cpuinfo.max_freq;
> +	if (!max_freq) {
> +		max_freq = __resolve_freq(policy, policy->cpuinfo.max_freq,
> +					  policy->cpuinfo.min_freq, policy->cpuinfo.max_freq,
> +					  CPUFREQ_RELATION_H);
> +	}
>   
>   	capped_freq = policy->max;
>   

LGTM.

NIT: I do wonder if we need a full __resolve_freq() each time. We could 
cache the highest achievable OPP on max_freq updates, but that's future 
optimization.

> ---
> [...]

Re: [PATCH] sched/fair: Only apply cpufreq pressure where frequency is invariant

[K Prateek Nayak]

Hello Hongyan,

On 9/9/2026 9:39 AM, Hongyan Xia wrote:
>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
>> index b898b6544069..97f4a3ba5107 100644
>> --- a/drivers/cpufreq/cpufreq.c
>> +++ b/drivers/cpufreq/cpufreq.c
>> @@ -2586,8 +2586,11 @@ static void cpufreq_update_pressure(struct cpufreq_policy *policy)
>>   
>>   	cpu = cpumask_first(policy->related_cpus);
>>   	max_freq = arch_scale_freq_ref(cpu);
>> -	if (!max_freq)
>> -		max_freq = policy->cpuinfo.max_freq;
>> +	if (!max_freq) {
>> +		max_freq = __resolve_freq(policy, policy->cpuinfo.max_freq,
>> +					  policy->cpuinfo.min_freq, policy->cpuinfo.max_freq,
>> +					  CPUFREQ_RELATION_H);
>> +	}
>>   
>>   	capped_freq = policy->max;
>>   
> 
> LGTM.

Thanks a ton for taking a look at the suggestion.

> 
> NIT: I do wonder if we need a full __resolve_freq() each time. We could 
> cache the highest achievable OPP on max_freq updates, but that's future 
> optimization.

Sure! We can cache it in the policy object during
cpufreq_policy_online().

Jianyong Wu would like to take a stab at it? If not, I can send it out
early next week.

-- 
Thanks and Regards,
Prateek

Disclaimer: Hygon emails are routed differently in our organization.
Response might be slightly delayed until my NNTP rule finds the email.
Sorry for any inconvenience.

Re: [PATCH] sched/fair: Only apply cpufreq pressure where frequency is invariant

[Vincent Guittot]

On Wed, 9 Sept 2026 at 12:05, K Prateek Nayak <kprateek.nayak@amd.com> wrote:
>
> Hello Hongyan,
>
> On 9/9/2026 9:39 AM, Hongyan Xia wrote:
> >> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> >> index b898b6544069..97f4a3ba5107 100644
> >> --- a/drivers/cpufreq/cpufreq.c
> >> +++ b/drivers/cpufreq/cpufreq.c
> >> @@ -2586,8 +2586,11 @@ static void cpufreq_update_pressure(struct cpufreq_policy *policy)
> >>
> >>      cpu = cpumask_first(policy->related_cpus);
> >>      max_freq = arch_scale_freq_ref(cpu);
> >> -    if (!max_freq)
> >> -            max_freq = policy->cpuinfo.max_freq;
> >> +    if (!max_freq) {
> >> +            max_freq = __resolve_freq(policy, policy->cpuinfo.max_freq,
> >> +                                      policy->cpuinfo.min_freq, policy->cpuinfo.max_freq,
> >> +                                      CPUFREQ_RELATION_H);

As long as the reference frequency used in cpufreq_update_pressure
remains fixed whetever boost is enabled or not this is ok. We don't
want the pressure to change when boost is enabled or disabled only
when policy->max changes.

> >> +    }
> >>
> >>      capped_freq = policy->max;
> >>
> >
> > LGTM.
>
> Thanks a ton for taking a look at the suggestion.
>
> >
> > NIT: I do wonder if we need a full __resolve_freq() each time. We could
> > cache the highest achievable OPP on max_freq updates, but that's future
> > optimization.
>
> Sure! We can cache it in the policy object during
> cpufreq_policy_online().
>
> Jianyong Wu would like to take a stab at it? If not, I can send it out
> early next week.
>
> --
> Thanks and Regards,
> Prateek
>
> Disclaimer: Hygon emails are routed differently in our organization.
> Response might be slightly delayed until my NNTP rule finds the email.
> Sorry for any inconvenience.

Re: [PATCH] sched/fair: Only apply cpufreq pressure where frequency is invariant

[Jianyong Wu]

在 2026/9/10 16:05, Vincent Guittot 写道:
> On Wed, 9 Sept 2026 at 12:05, K Prateek Nayak <kprateek.nayak@amd.com> wrote:
>>
>> Hello Hongyan,
>>
>> On 9/9/2026 9:39 AM, Hongyan Xia wrote:
>>>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
>>>> index b898b6544069..97f4a3ba5107 100644
>>>> --- a/drivers/cpufreq/cpufreq.c
>>>> +++ b/drivers/cpufreq/cpufreq.c
>>>> @@ -2586,8 +2586,11 @@ static void cpufreq_update_pressure(struct cpufreq_policy *policy)
>>>>
>>>>       cpu = cpumask_first(policy->related_cpus);
>>>>       max_freq = arch_scale_freq_ref(cpu);
>>>> -    if (!max_freq)
>>>> -            max_freq = policy->cpuinfo.max_freq;
>>>> +    if (!max_freq) {
>>>> +            max_freq = __resolve_freq(policy, policy->cpuinfo.max_freq,
>>>> +                                      policy->cpuinfo.min_freq, policy->cpuinfo.max_freq,
>>>> +                                      CPUFREQ_RELATION_H);
> 
> As long as the reference frequency used in cpufreq_update_pressure
> remains fixed whetever boost is enabled or not this is ok. We don't
> want the pressure to change when boost is enabled or disabled only
> when policy->max changes.
> 

Thanks for the clarification.

There is still an issue with intel_pstate (maybe also amd-pstate). 
Suppose that the boost frequency is 4 GHz,the maximum sustainable 
frequency is 3 GHz, and the policy is capped at 2 GHz.

With boost enabled:
policy->cpuinfo.max_freq = 4 GHz
policy->max = 2 GHz

With boost disabled:
policy->cpuinfo.max_freq = 3 GHz
policy->max = 2 GHz

Consequently, using cpuinfo.max_freq as the reference gives different 
frequency pressure depending on the boost state: 1 - 2/4 with boost 
enabled and 1 - 2/3 with boost disabled, even though policy->max remains 
unchanged.

Resolving cpuinfo.max_freq does not address this for intel_pstate, 
because it has no frequency table and __resolve_freq() returns 
cpuinfo.max_freq unchanged. This behavior is not introduced by the 
proposed change; it already exists with the current cpuinfo.max_freq 
fallback.

To keep frequency pressure invariant across boost state changes, it 
seems that we need a fixed maximum sustainable frequency as the 
reference. It should exclude boost frequencies and remain unchanged when 
boost is enabled or disabled. policy->max would remain the current 
effective policy limit:

boost enabled, uncapped: policy->max > max_sustainable_freq
boost disabled, uncapped: policy->max == max_sustainable_freq
capped: policy->max < max_sustainable_freq

The existing max_freq <= capped_freq check would produce zero pressure 
for both uncapped cases, while a cap below max_sustainable_freq would 
produce the same pressure regardless of the boost state.

Does this match the intended semantics? If so, the next question might 
be how to obtain the max_sustainable_freq.

Thanks,
Jianyong

>>>> +    }
>>>>
>>>>       capped_freq = policy->max;
>>>>
>>>
>>> LGTM.
>>
>> Thanks a ton for taking a look at the suggestion.
>>
>>>
>>> NIT: I do wonder if we need a full __resolve_freq() each time. We could
>>> cache the highest achievable OPP on max_freq updates, but that's future
>>> optimization.
>>
>> Sure! We can cache it in the policy object during
>> cpufreq_policy_online().
>>
>> Jianyong Wu would like to take a stab at it? If not, I can send it out
>> early next week.
>>
>> --
>> Thanks and Regards,
>> Prateek
>>
>> Disclaimer: Hygon emails are routed differently in our organization.
>> Response might be slightly delayed until my NNTP rule finds the email.
>> Sorry for any inconvenience.

Re: [PATCH] sched/fair: Only apply cpufreq pressure where frequency is invariant

[Jianyong Wu]

在 2026/9/9 18:04, K Prateek Nayak 写道:
> Hello Hongyan,
> 
> On 9/9/2026 9:39 AM, Hongyan Xia wrote:
>>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
>>> index b898b6544069..97f4a3ba5107 100644
>>> --- a/drivers/cpufreq/cpufreq.c
>>> +++ b/drivers/cpufreq/cpufreq.c
>>> @@ -2586,8 +2586,11 @@ static void cpufreq_update_pressure(struct cpufreq_policy *policy)
>>>    
>>>    	cpu = cpumask_first(policy->related_cpus);
>>>    	max_freq = arch_scale_freq_ref(cpu);
>>> -	if (!max_freq)
>>> -		max_freq = policy->cpuinfo.max_freq;
>>> +	if (!max_freq) {
>>> +		max_freq = __resolve_freq(policy, policy->cpuinfo.max_freq,
>>> +					  policy->cpuinfo.min_freq, policy->cpuinfo.max_freq,
>>> +					  CPUFREQ_RELATION_H);
>>> +	}
>>>    
>>>    	capped_freq = policy->max;
>>>    
>>
>> LGTM.
> 
> Thanks a ton for taking a look at the suggestion.
> 
>>
>> NIT: I do wonder if we need a full __resolve_freq() each time. We could
>> cache the highest achievable OPP on max_freq updates, but that's future
>> optimization.
> 
> Sure! We can cache it in the policy object during
> cpufreq_policy_online().
> 
> Jianyong Wu would like to take a stab at it? If not, I can send it out
> early next week.

Thanks for asking, I would happy to take a stab at this.

Based on Vincent's follow-up, I think we may need a different approach
to keep the reference frequency fixed across boost state changes.>

Re: [PATCH] sched/fair: Only apply cpufreq pressure where frequency is invariant

[jong wu]

在 2026/9/7 10:32, Hongyan Xia 写道:
> On 9/3/2026 10:04 AM, jong wu wrote:
>> 在 2026/9/2 17:37, Hongyan Xia 写道:
>>> On 9/2/2026 4:49 PM, jong wu wrote:
>>>> 在 2026/8/25 21:05, Vincent Guittot 写道:
>>>>> 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.
>>>>>
>>>>
>>>> Exactly. I think the root cause is that policy->max has different
>>>> semantics across cpufreq drivers. On Intel and most AMD machines it is
>>>> the maximum attainable frequency, i.e. the boost frequency when boost
>>>> is enabled. For acpi-cpufreq, however, policy->max is resolved from the
>>>> ACPI _PSS table, which does not contain the boost frequency.
>>>
>>> Proper solutions aside, I vaguely remember investigating scheduler
>>> issues on a Ryzen 7840U. That has acpi-cpufreq with only 3 OPPs. Boost
>>> frequencies are not included in those 3 and are much higher than the
>>> ACPI OPPs. I certainly managed to disable pstate and switched to
>>> acpi-cpufreq on it. I wonder if you can reproduce such issues on such a
>>> machine. Maybe this is a broader issue than we realize.
>>
>> That may well be the case, but so far I have only observed it on my own
>> machine, so I would rather not claim more than that yet.
>>
>> My current understanding is that the trigger would be the driver rather
>> than the vendor: if a system runs acpi-cpufreq and its boost frequency
>> is not present in the _PSS table, the same reasoning should apply. The
>> 7840U you describe -- 3 OPPs, boost well above the highest one -- looks
>> like it could fit that shape, but that remains a guess until it is
>> actually measured.
>>
>> I do not have a 7840U at hand. I will try to reproduce it on an Intel
>> or AMD box by forcing acpi-cpufreq (intel_pstate=disable /
>> amd_pstate=disable), then comparing the measured frequency against
>> policy->max with boost enabled and checking whether a non-zero cpufreq
>> pressure shows up while the system is unconstrained. I will report back
>> with the numbers once I have them.
> 
> I managed to reproduce the problem on an AMD 5900X. I added trace_printk
> outputs on cpufreq pressure updates. Under AMD pstate with boost
> frequencies I get:
> 
> [006] .....    34.096492: cpufreq_set_policy: CPU 1 has max_freq
> 4683471, max 4683471
> 
> You can see policy->cpuinfo.max_freq and policy->max are the same.
> 
> If I force disable pstate and use ACPI OPPs with schedutil but still
> with boost frequencies, I get:
> 
> [003] .....     4.697753: cpufreq_set_policy: CPU 1 has max_freq
> 4680714, max 3300000
> 
> So you can see policy->max includes no boost frequencies (3300000 is the
> highest OPP) and will trigger policy->max < policy->cpuinfo.max_freq,
> hence applying pressure when there is actually no pressure.
> 
> The conclusion is that yes, this is a wider problem than we realize. I
> suspect this might also be present in Intel CPUs with ACPI cpufreq.

Thanks for testing. I reproduced it on an AMD box too, and I agree it is
not AMD-specific: any driver that reports a non-boost policy->max while
cpuinfo.max_freq includes boost will hit the same path, so ACPI cpufreq
on Intel should be affected as well.

I will address that in a separate patch and we can continue the
discussion there.

Thanks,
Jianyong