Re: [PATCH v1] cpufreq: intel_pstate: Fix max_freq fallback in cpufreq_update_pressure()
From: Rafael J. Wysocki (Intel)
Date: Wed Sep 23 2026 - 11:00:52 EST
On Wed, Sep 23, 2026 at 4:42 PM Ricardo Neri
<ricardo.neri-calderon@xxxxxxxxxxxxxxx> wrote:
>
> 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>
>
> This patch did not break anything for me. I tested this in several Intel
> processors with asymmetric capacity capacity enabled. Tasks spread as
> expected when no cpufreq pressure is applied. Tasks duly migrate away when
> this pressure is applied to a subset of CPUs. They come back when the
> pressure is removed.
>
> Tested-by: Ricardo Neri <ricardo.neri-calderon@xxxxxxxxxxxxxxx> # Intel hybrid parts
Thank you!
In the absence of objections or concerns, I'll queue up this patch as
a fix for 7.3.