cpufreq: interactive: Exercise hispeed settings at a policy level
authorSaravana Kannan <skannan@codeaurora.org>
Wed, 15 Oct 2014 19:44:18 +0000 (12:44 -0700)
committerJohn Stultz <john.stultz@linaro.org>
Tue, 16 Feb 2016 21:53:06 +0000 (13:53 -0800)
commit54c3ec0a7bb945ca872788241e3820a92f3f508a
tree1338ff51c608a660da2f1f0594a673fa1851b5a5
parent4db1f0ac8761fc30d4e1230939d623a52517bdcc
cpufreq: interactive: Exercise hispeed settings at a policy level

If a heavy task migrates between otherwise idle CPUs in a policy during
every sample window, the above hispeed delay window for the CPUs would get
restarted for every sample window. Due to the continuous restart of above
hispeed delay window, none of the CPUs would ever pick a target frequency
higher than hispeed frequency. This causes the policy's frequency to be
stuck at hispeed freq even if the load justifies a higher frequency.

To fix this, the above high speed delay window is restarted only when the
policy frequency changes. This ensures that tasks migrating between CPUs in
a policy are handled correctly.

Also, the hispeed load/frequency heuristic is only necessary when the
information is insufficient to determine if the load on the CPU needs at
least hispeed frequency. When the policy frequency is already at or above
hispeed frequency, if the CPU load% based on policy frequency is not above
hispeed load, then the information is clearly sufficient to determine that
the load on the CPU does not need hispeed frequency.

Therefore, compute CPU load% (which is used only to compare against hispeed
load) based on policy frequency instead of CPU target frequency.

Change-Id: I8b5dfe6c50bee567a6719f0980e3f7757876ce4b
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
drivers/cpufreq/cpufreq_interactive.c