Re: [PATCH] cpufreq: Use a non-boost reference frequency for pressure calculation

[Jianyong Wu]

Hi Rafael,

> 
> On Sep 18, 2026, at 01:38, Rafael J. Wysocki (Intel) <rafael@xxxxxxxxxx> wrote:
> On Tue, Sep 15, 2026 at 9:03 AM Jianyong Wu <wujianyong@xxxxxxxx> wrote:
>> 
>> Commit d2d5c129d07e ("cpufreq: Make cpufreq_update_pressure() fall
>> back to cpuinfo.max_freq") introduced cpuinfo.max_freq as the reference
>> frequency for cpufreq pressure when arch_scale_freq_ref() returns zero.
>> 
>> However, cpuinfo.max_freq may include boost frequencies and therefore
>> does not necessarily represent the maximum sustainable frequency.
> 
> And then it really matters what is sustainable and for how long.

I think it's confusing to say "sustainable freq" in cpufreq part. I mean the maximum
cpu frequency below boost here. For acpi-cpufreq, it’s P0. For amd-pstate, it’s
nominal frequency. But I can't find a better word.

> 
>> On some systems using acpi-cpufreq, cpuinfo.max_freq includes boost while
>> the frequency table only contains non-boost frequencies.
> 
> In which case selecting freq_table[0] may give the processor a license
> to go to the turbo (or boost) frequency range.

Yeah, selecting freq_table[0] may also mean cpu can go to boost frequency. 
But the value doesn't denote that. freq_table[0] is assigned  to policy->max which
is compared with policy->cpuinfo.max_freq. The difference between them makes
the cpu pressure which is not intended.
 
> 
>> Consequently, cpufreq pressure remains nonzero even without an additional
>> frequency limit.
> 
> So when and where does this matter?

I test it on amd, intel and hygon box. Once acpi-cpufreq is used, the unexpected
cpu pressure appears when there is no cpu frequency capped and boost is enabled.

The wrong cpu pressure affects load balancing. For example, Cache aware
scheduling wants to aggregate task in a LLC using 50% of the whole LLC capacity.
Before commit d2d5c129d07e, everything is OK. But with that commit and using
acpi-cpufreq and with boost on, cache aware scheduling can’t aggregate
task to occupy 50% of the LLC by default as the cpu capacity in the LLC is reduced. 
> 
>> Furthermore, drivers may update cpuinfo.max_freq when boost is enabled
>> or disabled. With a fixed policy limit below the maximum non-boost
>> frequency, this changes the pressure reference and hence the reported
>> pressure, although the non-boost frequency limit remains unchanged.
> 
> If the capacity is updated though along with the cpuinfo.max_freq
> change, then this is all fine because the pressure is then computed
> relative to the new capacity.  intel_pstate does that.

This follows Vincent. Reference Vincent’s words [1]:

"As long as the reference frequency used in cpufreq_update_pressure
remains fixed whetever boost is enabled or not this is ok. We don't
want the pressure to change when boost is enabled or disabled only
when policy->max changes."

If intel_pstate let the cpu pressure vary with the boost on or off, what
about acpi-cpufreq. It’s not easy to do the same thing there. I think it
is better to give a uniform behavior across different cpufreq driver.

[1] https://lore.kernel.org/all/CAKfTPtBji8dkr5ixhtZjkyrWLA68TF-KHLrNYWoewPWLyuUd4A@xxxxxxxxxxxxxx/
> 
>> Add max_sustainable_freq to struct cpufreq_cpuinfo to provide a reference
>> frequency excluding boost. Populate it from the nominal frequency in
>> amd-pstate and cppc_cpufreq, the maximum non-turbo frequency in
>> intel_pstate, and the highest frequency-table entry in acpi-cpufreq.
>> 
>> Use this value when arch_scale_freq_ref() returns zero. Preserve the
>> existing cpuinfo.max_freq fallback for drivers that leave the new field
>> at zero.
>> 
>> Tested with acpi-cpufreq, intel_pstate, and amd-pstate in active and
>> passive modes. With no additional frequency limit, pressure is zero.
>> With a fixed limit below the non-boost reference frequency, pressure
>> remains unchanged across boost transitions.
> 
> Which may not be what is intended.

Same as above: IMO, with a fixed cap, the pressure should not change
just because boost is toggled.

Thanks
Jianyong