aboutsummaryrefslogtreecommitdiff
path: root/drivers/ata
diff options
context:
space:
mode:
authorSaravana Kannan <skannan@codeaurora.org>2014-10-15 12:44:18 -0700
committerRuchi Kandoi <kandoiruchi@google.com>2015-05-19 19:37:44 +0000
commitcc7b3da7145e5b1bd780df08e7ce745f48b591e9 (patch)
tree0835c3ffadc336ff1051b3d88aa6a8edd5368601 /drivers/ata
parent1f556b97785cb9c42b91bf8ef3686aa1dc9d3711 (diff)
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>
Diffstat (limited to 'drivers/ata')
0 files changed, 0 insertions, 0 deletions