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

[Jianyong Wu]

在 2026/9/9 18:04, K Prateek Nayak 写道:
> 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);
> > > +	}
> > >    
> > >    	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 for asking, I would happy to take a stab at this.

Based on Vincent's follow-up, I think we may need a different approach
to keep the reference frequency fixed across boost state changes.>