Re: [PATCH v7 1/2] cpufreq: Remove per-CPU QoS constraint

[Pierre Gondois]

On 3/26/26 05:37, Viresh Kumar wrote:
> What do you mean by per-CPU QOS constraint in Subject ? This is per-policy
> constraint and you are not removing it, you are just avoiding to update it in
> one of the paths.
Right, I ll update the patch header
> On 25-03-26, 17:52, Pierre Gondois wrote:
> > policy->max_freq_req QoS constraint represents the maximal allowed
> > frequency than can be requested. It is set by:
> > - writing to policyX/scaling_max sysfs file
> > - toggling the cpufreq/boost sysfs file
> >
> > Upon calling freq_qos_update_request(), a successful update
> > of the max_freq_req value triggers cpufreq_notifier_max(),
> > followed by cpufreq_set_policy() which update the requested
> > frequency for the policy.
> > If the new max_freq_req value is not different from the
> > original value, no frequency update is triggered.
> >
> > In a specific sequence of toggling:
> > - cpufreq/boost sysfs file
> > - CPU hot-plugging
> > a CPU could end up with boost enabled but running at the
> > maximal non-boost frequency, cpufreq_notifier_max() not being
> > triggered. The following fixed that:
> > commit 1608f0230510 ("cpufreq: Fix re-boost issue after hotplugging
> > a CPU")
> >
> > The following:
> > commit dd016f379ebc ("cpufreq: Introduce a more generic way to
> > set default per-policy boost flag")
> > also fixed the issue by correctly setting the max_freq_req
> > constraint of a policy that is re-activated. This makes the
> > first fix unnecessary.
> >
> > As the original issue is fixed by another method,
> > this patch reverts:
> > commit 1608f0230510 ("cpufreq: Fix re-boost issue after hotplugging
> > a CPU")
> Looks okay otherwise.