Re: [PATCH v1] cpufreq: intel_pstate: Fix max_freq fallback in cpufreq_update_pressure()

[Chen Yu]

On Mon, Sep 21, 2026 at 09:12:00PM +0200, Rafael J. Wysocki wrote:
> From: "Rafael J. Wysocki" <rafael.j.wysocki@xxxxxxxxx>
> 
> After commit d2d5c129d07e ("cpufreq: Make cpufreq_update_pressure() fall
> back to cpuinfo.max_freq"), cpufreq pressure appears in the CPU load
> balancer unexpectedly in some cases in which it was not present before,
> leading to confusion and uncertainty.
> 
> Clearly, the scheduler assumes that cpufreq pressure will not be set
> unless the capacity reference frequency of the CPU is known, and the
> commit mentioned above violates that assumption.
> 
> However, in some cases the capacity reference frequency of the CPU is
> in fact known even though arch_scale_freq_ref() returns 0 and in those
> cases it should be possible to set cpufreq pressure as appropriate.
> 
> For this purpose, introduce a new cpufreq driver callback returning
> the CPU capacity reference frequency, .scale_freq_ref(), and make
> cpufreq_update_pressure() invoke it, if present, instead of falling
> back to cpuinfo.max_freq unconditionally.
> 
> Add that callback to the intel_pstate driver and make it return 0 unless
> the scale-invariant capacity of the given CPU has been explicitly set,
> in which cases its reference frequency is always cpuinfo.max_freq.
> 
> Fixes: d2d5c129d07e ("cpufreq: Make cpufreq_update_pressure() fall back to cpuinfo.max_freq")
> Reported-by: Jianyong Wu <wujianyong@xxxxxxxx>
> Closes: https://lore.kernel.org/linux-pm/20260915065747.1671965-1-wujianyong@xxxxxxxx/
> Tested-by: Jianyong Wu <wujianyong@xxxxxxxx>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>

I did not observe any issue on a 4LLCs per node Xeon server when running
cache-aware-schedulings santity test,

Tested-by: Chen Yu <yu.c.chen@xxxxxxxxx>

thanks,
Chenyu