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

[Viresh Kumar]

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.

-- 
viresh