aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorViresh Kumar <viresh.kumar@linaro.org>2017-08-14 05:20:16 -0400
committerRafael J. Wysocki <rafael.j.wysocki@intel.com>2017-08-17 19:35:19 -0400
commitc49cbc19b31e069cb344921c7286d7549767d10e (patch)
tree17619f692f3bea27eabe3155fefe92d9ed9e9383
parente2cabe48c20efb174ce0c01190f8b9c5f3ea1d13 (diff)
cpufreq: schedutil: Always process remote callback with slow switching
The frequency update from the utilization update handlers can be divided into two parts: (A) Finding the next frequency (B) Updating the frequency While any CPU can do (A), (B) can be restricted to a group of CPUs only, depending on the current platform. For platforms where fast cpufreq switching is possible, both (A) and (B) are always done from the same CPU and that CPU should be capable of changing the frequency of the target CPU. But for platforms where fast cpufreq switching isn't possible, after doing (A) we wake up a kthread which will eventually do (B). This kthread is already bound to the right set of CPUs, i.e. only those which can change the frequency of CPUs of a cpufreq policy. And so any CPU can actually do (A) in this case, as the frequency is updated from the right set of CPUs only. Check cpufreq_can_do_remote_dvfs() only for the fast switching case. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-rw-r--r--kernel/sched/cpufreq_schedutil.c9
1 files changed, 7 insertions, 2 deletions
diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index 69571ee6a175..a07f17a5f38f 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -84,13 +84,18 @@ static bool sugov_should_update_freq(struct sugov_policy *sg_policy, u64 time)
84 * 84 *
85 * However, drivers cannot in general deal with cross-cpu 85 * However, drivers cannot in general deal with cross-cpu
86 * requests, so while get_next_freq() will work, our 86 * requests, so while get_next_freq() will work, our
87 * sugov_update_commit() call may not. 87 * sugov_update_commit() call may not for the fast switching platforms.
88 * 88 *
89 * Hence stop here for remote requests if they aren't supported 89 * Hence stop here for remote requests if they aren't supported
90 * by the hardware, as calculating the frequency is pointless if 90 * by the hardware, as calculating the frequency is pointless if
91 * we cannot in fact act on it. 91 * we cannot in fact act on it.
92 *
93 * For the slow switching platforms, the kthread is always scheduled on
94 * the right set of CPUs and any CPU can find the next frequency and
95 * schedule the kthread.
92 */ 96 */
93 if (!cpufreq_can_do_remote_dvfs(sg_policy->policy)) 97 if (sg_policy->policy->fast_switch_enabled &&
98 !cpufreq_can_do_remote_dvfs(sg_policy->policy))
94 return false; 99 return false;
95 100
96 if (sg_policy->work_in_progress) 101 if (sg_policy->work_in_progress)