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

在 2026/9/2 17:37, Hongyan Xia 写道:

On 9/2/2026 4:49 PM, jong wu wrote:

quoted

在 2026/8/25 21:05, Vincent Guittot 写道:

quoted

On Mon, 24 Aug 2026 at 15:06, Jianyong Wu [off-list ref]
wrote:

quoted

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>

quoted

[...]