diff options
author | Viresh Kumar <viresh.kumar@linaro.org> | 2017-11-08 20:23:55 +0530 |
---|---|---|
committer | Rafael J. Wysocki <rafael.j.wysocki@intel.com> | 2017-11-08 23:59:33 +0100 |
commit | 07458f6a5171d97511dfbdf6ce549ed2ca0280c7 (patch) | |
tree | 5c55fa92fc2e2971e2654839c3df1535ed96c40b /drivers | |
parent | d62d813c0d714a2d0aaf3d796a7a51ae60bf5470 (diff) | |
download | linux-rpi-07458f6a5171d97511dfbdf6ce549ed2ca0280c7.tar.gz linux-rpi-07458f6a5171d97511dfbdf6ce549ed2ca0280c7.tar.bz2 linux-rpi-07458f6a5171d97511dfbdf6ce549ed2ca0280c7.zip |
cpufreq: schedutil: Reset cached_raw_freq when not in sync with next_freq
'cached_raw_freq' is used to get the next frequency quickly but should
always be in sync with sg_policy->next_freq. There is a case where it is
not and in such cases it should be reset to avoid switching to incorrect
frequencies.
Consider this case for example:
- policy->cur is 1.2 GHz (Max)
- New request comes for 780 MHz and we store that in cached_raw_freq.
- Based on 780 MHz, we calculate the effective frequency as 800 MHz.
- We then see the CPU wasn't idle recently and choose to keep the next
freq as 1.2 GHz.
- Now we have cached_raw_freq is 780 MHz and sg_policy->next_freq is
1.2 GHz.
- Now if the utilization doesn't change in then next request, then the
next target frequency will still be 780 MHz and it will match with
cached_raw_freq. But we will choose 1.2 GHz instead of 800 MHz here.
Fixes: b7eaf1aab9f8 (cpufreq: schedutil: Avoid reducing frequency of busy CPUs prematurely)
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Cc: 4.12+ <stable@vger.kernel.org> # 4.12+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Diffstat (limited to 'drivers')
0 files changed, 0 insertions, 0 deletions