On Sat, Jun 10, 2017 at 2:11 AM, Joel Fernandes joelaf@google.com wrote:
On Fri, Jun 9, 2017 at 3:15 AM, Viresh Kumar viresh.kumar@linaro.org wrote:
While reducing frequency if there are no frequencies available between "current" and "next" calculated frequency, then the core will never select the "next" frequency.
For example, consider the possible range of frequencies as 900 MHz, 1 GHz, 1.1 GHz, and 1.2 GHz. If the current frequency is 1.1 GHz and the next frequency (based on current utilization) is 1 GHz, then the schedutil governor will try to set the average of these as the next frequency (i.e. 1.05 GHz).
Because we always try to find the lowest frequency greater than equal to the target frequency, cpufreq_driver_resolve_freq() will end up returning 1.1 GHz only. And we will not be able to reduce the frequency eventually. The worst hit is the policy->min frequency as that will never get selected after the frequency is increased once.
But once utilization goes to 0, it will select the min frequency (because it selects lowest frequency >= target)?
Never mind my comment about util 0, I see the problem you mention. However I feel that this entire series adds complexity all to handle the case of a false cache-miss which I think might not be that bad, and the tradeoff with complexity/readability of the code kind of negates the benefit. That's just my opinion about it fwiw.
Thanks, Joel