summaryrefslogtreecommitdiff
path: root/lib/locking-selftest-wsem.h
diff options
context:
space:
mode:
authorRafael J. Wysocki <rafael.j.wysocki@intel.com>2016-05-06 01:30:37 +0200
committerRafael J. Wysocki <rafael.j.wysocki@intel.com>2016-05-06 14:24:23 +0200
commit9485e4ca0b486248ce07d7dd1411a1080d24ed0d (patch)
tree09ba6e57225a428c18bd44da9b764ef4e3a974ae /lib/locking-selftest-wsem.h
parente59a8f7ff4573fd54f1acec0e29280a6556fdde9 (diff)
cpufreq: governor: Fix handling of special cases in dbs_update()
As reported in KBZ 69821: "With CONFIG_HZ_PERIODIC=y cpu stays at the lowest frequcency 800MHz even if usage goes to 100%, frequency does not scale up, the governor in use is ondemand. Neither works conservative. Performance and userspace governors work as expected. With CONFIG_NO_HZ_IDLE or CONFIG_NO_HZ_FULL cpu scales up with ondemand as expected." Analysis carried out by Chen Yu leads to the conclusion that the observed issue is due to idle_time in dbs_update() representing a negative number in which case the function will return 0 as the load (unless load is greater than 0 for another CPU sharing the policy), although that need not be the right choice. Indeed, idle_time representing a negative number means that during the last sampling interval the CPU was almost 100% busy on the rough average, so 100 should be returned as the load in that case. Modify the code accordingly and rearrange it to clarify the handling of all of the special cases in it. While at it, also avoid returning zero as the load if time_elapsed is 0 (it doesn't really make sense to return 0 then). Link: https://bugzilla.kernel.org/show_bug.cgi?id=69821 Tested-by: Chen Yu <yu.c.chen@intel.com> Tested-by: Timo Valtoaho <timo.valtoaho@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Diffstat (limited to 'lib/locking-selftest-wsem.h')
0 files changed, 0 insertions, 0 deletions