Re: [PATCH 2/3] cpufreq: Avoid redundant target() calls for unchanged limits

[Rafael J. Wysocki]

On Thu, May 21, 2026 at 4:33 PM Viresh Kumar <viresh.kumar@xxxxxxxxxx> wrote:
>
> On 21-05-26, 21:58, Zhongqiu Han wrote:
> > > diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> > > index 1292da53e5fc..7f19ec6b70ba 100644
> > > --- a/drivers/cpufreq/intel_pstate.c
> > > +++ b/drivers/cpufreq/intel_pstate.c
> > > @@ -2942,6 +2942,7 @@ static void intel_pstate_adjust_policy_max(struct cpudata *cpu,
> > >         policy->max > cpu->pstate.max_freq) {
> > >             pr_debug("policy->max > max non turbo frequency\n");
> > >             policy->max = policy->cpuinfo.max_freq;
> > > +           policy->update_limits = true;
> >
> >
> > Could this be redundant?
>
> Yeah, this won't even compile I think. In my first attempt I tried to
> make the update_limits change from within verify in cpufreq.h and that
> caused a build failure and then I moved to cpufreq_set_policy() and
> forgot to fix this one. And my arm64 build didn't cover this file.
> Sorry about that.
>
> > It seems that intel_pstate_adjust_policy_max() is only triggered when
> > !hwp_active, whereas CPUFREQ_NEED_UPDATE_LIMITS is set when
> > hwp_active is enabled. If so, the update_limits flag set here may not
> > actually be consumed, as __cpufreq_driver_target() would skip the
> > update_limits check for drivers without CPUFREQ_NEED_UPDATE_LIMITS.
>
> Good catch.
>
> Rafael, is the understanding correct ? I can drop the intel_pstate
> change in that case.

Yes, it is.  intel_pstate only sets CPUFREQ_NEED_UPDATE_LIMITS when
hwp_active is set, in which case intel_pstate_adjust_policy_max() is a
NOP.