Re: [PATCH 2/2] cpufreq: governor: Apply limits with requested_freq or next_freq

[zhenglifeng (A)]

On 3/5/2026 2:21 PM, Viresh Kumar wrote:
> On 10-02-26, 19:54, Lifeng Zheng wrote:
>> For conservative, ondemand and schedutil governor,
>> cpufreq_policy_apply_limits() is called in .limits(). This function updates
>> the target because the limits (policy->max and policy->min) may be changed.
>> However, it uses policy->cur as the reference for the target frequency.
>> This may cause some problems because the value of policy->cur is influenced
>> by a variety of factors.
>>
>> For example, for some reason, the platform determines a final
>> frequency divided from the frequency distributed by the OS, and this is
>> reflected in policy->cur. After that, cpufreq_policy_apply_limits() is
>> called and because policy->cur is out of limmit, policy->min will be used
>> as the new target.
> 
> Yes, but policy->min should be higher than current frequency then. The algorithm
> has derived policy->cur to be a reasonable frequency, and we are taking decision
> based on that, which looks absolutely fine. We can fix the algorithm
> (governors), so they choose the right frequency, but this logic looks to be okay
> I guess.
> 
>> This caused the real frequency lower but it's
>> unnecessary.
> 
> Lower than what ? It is still higher than the last configured frequency.

Hi Viresh,

You can take a look at the example I showed in the cover letter. On our
platform, under certain special circumstances, the final adjusted frequency
is obtained by dividing the frequency sent by the OS. Therefore, when the
frequency of OS updates decreases, it will also lead to a decrease in the
final frequency. Furthermore, since requested_freq remains at the highest
frequency, the conservative governor will not update the frequency again
until the utilization rate drops. This will cause the frequency issued by
the OS to remain at the lowest frequency even after the frequency division
is restored.

>