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

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