Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752725AbdGHGOw (ORCPT ); Sat, 8 Jul 2017 02:14:52 -0400 Received: from mail-oi0-f44.google.com ([209.85.218.44]:35078 "EHLO mail-oi0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752684AbdGHGOu (ORCPT ); Sat, 8 Jul 2017 02:14:50 -0400 MIME-Version: 1.0 In-Reply-To: References: <1499189651-18797-1-git-send-email-patrick.bellasi@arm.com> <1499189651-18797-5-git-send-email-patrick.bellasi@arm.com> From: Joel Fernandes Date: Fri, 7 Jul 2017 23:14:48 -0700 Message-ID: Subject: Re: [PATCH v2 4/6] cpufreq: schedutil: update CFS util only if used To: Vikram Mulukutla Cc: Patrick Bellasi , LKML , Linux PM , Ingo Molnar , Peter Zijlstra , "Rafael J . Wysocki" , Viresh Kumar , Vincent Guittot , Juri Lelli , Andres Oportus , Todd Kjos , Morten Rasmussen , Dietmar Eggemann , linux-kernel-owner@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2165 Lines: 59 Hi Vikram, On Thu, Jul 6, 2017 at 11:44 PM, Vikram Mulukutla wrote: > 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 >> Cc: Ingo Molnar >> Cc: Peter Zijlstra >> Cc: Rafael J. Wysocki >> Cc: Viresh Kumar >> Cc: linux-kernel@vger.kernel.org >> Cc: linux-pm@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? > I didn't follow, Could you elaborate more why you think the patch helps with the case where max changes while the per-cpu rq lock held? thanks, -Joel