Re: [PATCH v2 4/6] cpufreq: schedutil: update CFS util only if used

From: Vikram Mulukutla
Date: Fri Jul 07 2017 - 02:44:18 EST

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.bellasi@xxxxxxx>
Cc: Ingo Molnar <mingo@xxxxxxxxxx>
Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
Cc: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>
Cc: Viresh Kumar <viresh.kumar@xxxxxxxxxx>
Cc: linux-kernel@xxxxxxxxxxxxxxx
Cc: linux-pm@xxxxxxxxxxxxxxx
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))

- sugov_get_util(&util, &max);

+ 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?


Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project