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