Re: [PATCH 0/2] cpufreq: governor: Apply limits with target_freq instead of policy->cur

["zhenglifeng (A)" <zhenglifeng1@huawei.com>]

On 3/10/2026 12:29 PM, Viresh Kumar wrote:
> On 10-03-26, 10:22, zhenglifeng (A) wrote:
>> In the example I showed above, policy->cur will become 1GHz when someone
>> query cpuinfo_cur_freq, because the real freq is 500MHz. After that,
>> conservative governor has to take some time to get to the max freq again
>> step by step in your code.
> 
> The problem is that your platform is doing some tricky stuff (by
> changing the frequency for some reason) and it expects the governor to
> still work the same. The software is trying to get a target frequency
> based on an algorithm and you are ending up breaking it. If this is
> software controlled (instead of hardware), I think a better solution
> is to play with QoS requests and limit the policy->max frequency, so
> the cpufreq core remains in sync instead of reducing the underlying
> frequency without informing the software. All cpufreq core can do now
> is go adjust based on what you are doing. Yes, conservative governor
> will start again from scratch here but this is what you are doing
> anyways. Either, don't change the underlying freq or use a different
> governor. I don't know how this can be fixed otherwise.
> 
>> I still believe using policy->cur to update target in
>> cpufreq_policy_apply_limits() is not very reasonable, because OS never
>> knows what the platform will do to affect the final frequency.
> 
> The software is doing the right thing by using the cached current
> frequency (best known to it).
> 
> We are using policy->cur at too many places and we will not be able to
> change all of them assuming the hardware is not in sync with the
> request made earlier. The change you propose may fix your issue for
> time being, but it is just a band-aid which I don't want to apply.
> When the hardware changes underlying freq, there are far too many
> things broken elsewhere too.
> 

I basically agree with what you said. But I have a little question. Do you
think the target freq should be updated when querying cpuinfo_cur_freq? I
think it should only be updated by governor or when limits changed.