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

[jong wu]

在 2026/9/7 16:37, K Prateek Nayak 写道:
> On 9/7/2026 1:37 PM, K Prateek Nayak wrote:
> > So, I've been trying to understand these bits and looking at
> > cpufreq_policy_init_qos(), the "policy->cpuinfo.max_freq" should be the
> > frequency including the boost range but I see cpufreq_update_pressure()
> > and it says:
> >
> >      max_freq = arch_scale_freq_ref(cpu);
> >      if (!max_freq)
> >          max_freq = policy->cpuinfo.max_freq;
> >
> >      capped_freq = policy->max;
> >
> >      /*
> >       * Handle properly the boost frequencies, which should simply clean
> >       * the cpufreq pressure value.
> >       */
> >      if (max_freq <= capped_freq) {
> >          ...
> >      }
> >
> >
> > Looking at this, I feel "policy->cpuinfo.max_freq" should not include
> > the boost frequency, or x86 should implement a arch_scale_freq_ref()
> > to know when boost is enabled vs disabled.
> >
> > If cpufreq_update_pressure() indeed has to disregard boost frequency,
> > and anything above P0 is not considered as pressure, we can simply
> > do:
> >
> > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> > index b898b6544069..068e6d6e15a1 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->max, policy->min,
>
> My bad, that should have been other way around and use the cpuinfo
> fields to prevent capping based on policy limits. Updated diff:
>
> 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;
>   
> ---
>
> > +					  CPUFREQ_RELATION_H);
> > +	}
> >   
> >   	capped_freq = policy->max;
> >   
> > ---
> >
> > __resolve_freq() will cap "policy->cpuinfo.max_freq" based on the freq_table
> > entries if it exists (acpi-cpufreq), or otherwise return
> > "policy->cpuinfo.max_freq" as is for drivers that uses CPPC based scaling
> > (amd-pstate, intel_pstate).
> >
> > Thoughts?
I think this is the right way to resolve the issue.  I had written a
patch for it as well, but it is more complex than yours, so I have made
a small change on top of your version instead.  On my machine, where
cpuinfo_max_freq (3100000) sits above the highest _PSS entry (2700000),
the CPU capacity is back to 1024 with it applied.  I will add a
Suggested-by: for you since the approach is yours - if you would rather
post it under your own authorship, say the word and I will stay out of
the way.

Thanks
Jianyong

>