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

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