On 2017-07-04 10:34, Patrick Bellasi wrote:
Currently the utilization of the FAIR class is collected before locking
the policy. Although that should not be a big issue for most cases, we
also don't really know how much latency there can be between the
utilization reading and its usage.
Let's get the FAIR utilization right before its usage to be better in
sync with the current status of a CPU.
Signed-off-by: Patrick Bellasi <patrick.bell...@arm.com>
Cc: Ingo Molnar <mi...@redhat.com>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
Cc: Viresh Kumar <viresh.ku...@linaro.org>
Cc: linux-kernel@vger.kernel.org
Cc: linux...@vger.kernel.org
---
kernel/sched/cpufreq_schedutil.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/kernel/sched/cpufreq_schedutil.c
b/kernel/sched/cpufreq_schedutil.c
index 98704d8..df433f1 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -308,10 +308,9 @@ static void sugov_update_shared(struct
update_util_data *hook, u64 time,
if (unlikely(current == sg_policy->thread))
return;
- sugov_get_util(&util, &max);
-
raw_spin_lock(&sg_policy->update_lock);
+ sugov_get_util(&util, &max);
sg_cpu->util = util;
sg_cpu->max = max;
Given that the utilization update hooks are called with the per-cpu rq
lock held (for all classes), I don't think PELT utilization can change
throughout the lifetime of the cpufreq_update_{util,this_cpu} call? Even
with Viresh's remote cpu callback series we'd still have to hold the rq
lock across cpufreq_update_util.. what can change today is 'max'
(arch_scale_cpu_capacity) when a cpufreq policy is shared, so the patch
is still needed for that reason I think?
Thanks,
Vikram
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
