From 9de6d75d464ba5039461f282cf1a307eb50a9690 Mon Sep 17 00:00:00 2001 From: Wei Wang Date: Wed, 24 Jun 2020 15:03:27 -0700 Subject: [PATCH] ANDROID: cpufreq: schedutil: drop cache when update skipped due to rate limit When frequency limits changed faster than sugov_up_down_rate_limit permits, the frequency change will be ignored. When a demanding workload runs with thermal governor which adjusts limits frequently and frequency relax action missed, the thermal governor will happy to settle (no further update on limit as thermal condition is maintained). So there won't be any new limits change. As workload continues to occupy the CPU, the votes from scheduler is all not updated. All these leads to a situation where the workload stuck at a low frequency until quits. If a frequency change is dropped due to rate limit, we should drop the cache. Besides the above mentioned limits changed case, there are also other cases when frequency update could be dropped. Bug: 159936782 Bug: 158863204 Signed-off-by: Wei Wang Change-Id: I9db69cd3e03f949cfe9a9a416fd33eea3907deec --- kernel/sched/cpufreq_schedutil.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c index 4c8ecbf0df69..765ec8146764 100644 --- a/kernel/sched/cpufreq_schedutil.c +++ b/kernel/sched/cpufreq_schedutil.c @@ -133,8 +133,11 @@ static bool sugov_update_next_freq(struct sugov_policy *sg_policy, u64 time, if (sg_policy->next_freq == next_freq) return false; - if (sugov_up_down_rate_limit(sg_policy, time, next_freq)) + if (sugov_up_down_rate_limit(sg_policy, time, next_freq)) { + /* Reset cached freq as next_freq is not changed */ + sg_policy->cached_raw_freq = 0; return false; + } sg_policy->next_freq = next_freq; sg_policy->last_freq_update_time = time;