Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751834AbdGGGoN (ORCPT ); Fri, 7 Jul 2017 02:44:13 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:41038 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750886AbdGGGoL (ORCPT ); Fri, 7 Jul 2017 02:44:11 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 06 Jul 2017 23:44:09 -0700 From: Vikram Mulukutla To: Patrick Bellasi Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, Ingo Molnar , Peter Zijlstra , "Rafael J . Wysocki" , Viresh Kumar , Vincent Guittot , Juri Lelli , Joel Fernandes , Andres Oportus , Todd Kjos , Morten Rasmussen , Dietmar Eggemann , linux-kernel-owner@vger.kernel.org Subject: Re: [PATCH v2 4/6] cpufreq: schedutil: update CFS util only if used In-Reply-To: <1499189651-18797-5-git-send-email-patrick.bellasi@arm.com> References: <1499189651-18797-1-git-send-email-patrick.bellasi@arm.com> <1499189651-18797-5-git-send-email-patrick.bellasi@arm.com> Message-ID: User-Agent: Roundcube Webmail/1.2.5 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1950 Lines: 52 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? Thanks, Vikram -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project