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

> [...]