Re: [PATCH] sched/fair: Only apply cpufreq pressure where frequency is invariant

[Jianyong Wu]

在 2026/9/10 16:05, Vincent Guittot 写道:
> On Wed, 9 Sept 2026 at 12:05, K Prateek Nayak <kprateek.nayak@xxxxxxx> wrote:
> > Hello Hongyan,
> >
> > On 9/9/2026 9:39 AM, Hongyan Xia wrote:
> > > > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> > > > index b898b6544069..97f4a3ba5107 100644
> > > > --- a/drivers/cpufreq/cpufreq.c
> > > > +++ b/drivers/cpufreq/cpufreq.c
> > > > @@ -2586,8 +2586,11 @@ static void cpufreq_update_pressure(struct cpufreq_policy *policy)
> > > >
> > > >       cpu = cpumask_first(policy->related_cpus);
> > > >       max_freq = arch_scale_freq_ref(cpu);
> > > > -    if (!max_freq)
> > > > -            max_freq = policy->cpuinfo.max_freq;
> > > > +    if (!max_freq) {
> > > > +            max_freq = __resolve_freq(policy, policy->cpuinfo.max_freq,
> > > > +                                      policy->cpuinfo.min_freq, policy->cpuinfo.max_freq,
> > > > +                                      CPUFREQ_RELATION_H);
>
> 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.

Thanks for the clarification.

There is still an issue with intel_pstate (maybe also amd-pstate). 
Suppose that the boost frequency is 4 GHz,the maximum sustainable 
frequency is 3 GHz, and the policy is capped at 2 GHz.

With boost enabled:
policy->cpuinfo.max_freq = 4 GHz
policy->max = 2 GHz

With boost disabled:
policy->cpuinfo.max_freq = 3 GHz
policy->max = 2 GHz

Consequently, using cpuinfo.max_freq as the reference gives different 
frequency pressure depending on the boost state: 1 - 2/4 with boost 
enabled and 1 - 2/3 with boost disabled, even though policy->max remains 
unchanged.

Resolving cpuinfo.max_freq does not address this for intel_pstate, 
because it has no frequency table and __resolve_freq() returns 
cpuinfo.max_freq unchanged. This behavior is not introduced by the 
proposed change; it already exists with the current cpuinfo.max_freq 
fallback.

To keep frequency pressure invariant across boost state changes, it 
seems that we need a fixed maximum sustainable frequency as the 
reference. It should exclude boost frequencies and remain unchanged when 
boost is enabled or disabled. policy->max would remain the current 
effective policy limit:

boost enabled, uncapped: policy->max > max_sustainable_freq
boost disabled, uncapped: policy->max == max_sustainable_freq
capped: policy->max < max_sustainable_freq

The existing max_freq <= capped_freq check would produce zero pressure 
for both uncapped cases, while a cap below max_sustainable_freq would 
produce the same pressure regardless of the boost state.

Does this match the intended semantics? If so, the next question might 
be how to obtain the max_sustainable_freq.

Thanks,
Jianyong

> > > > +    }
> > > >
> > > >       capped_freq = policy->max;
> > >
> > > LGTM.
> >
> > Thanks a ton for taking a look at the suggestion.
> >
> > > NIT: I do wonder if we need a full __resolve_freq() each time. We could
> > > cache the highest achievable OPP on max_freq updates, but that's future
> > > optimization.
> >
> > Sure! We can cache it in the policy object during
> > cpufreq_policy_online().
> >
> > Jianyong Wu would like to take a stab at it? If not, I can send it out
> > early next week.
> >
> > --
> > Thanks and Regards,
> > Prateek
> >
> > Disclaimer: Hygon emails are routed differently in our organization.
> > Response might be slightly delayed until my NNTP rule finds the email.
> > Sorry for any inconvenience.