Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933498AbdGKTI7 (ORCPT ); Tue, 11 Jul 2017 15:08:59 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:40544 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932483AbdGKTI6 (ORCPT ); Tue, 11 Jul 2017 15:08:58 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org BE440607C4 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=skannan@codeaurora.org Message-ID: <59652247.5070900@codeaurora.org> Date: Tue, 11 Jul 2017 12:08:55 -0700 From: Saravana Kannan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 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 Subject: Re: [PATCH v2 1/6] cpufreq: schedutil: ignore sugov kthreads References: <1499189651-18797-1-git-send-email-patrick.bellasi@arm.com> <1499189651-18797-2-git-send-email-patrick.bellasi@arm.com> In-Reply-To: <1499189651-18797-2-git-send-email-patrick.bellasi@arm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2409 Lines: 64 On 07/04/2017 10:34 AM, Patrick Bellasi wrote: > In system where multiple CPUs shares the same frequency domain a small > workload on a CPU can still be subject to frequency spikes, generated by > the activation of the sugov's kthread. > > Since the sugov kthread is a special RT task, which goal is just that to > activate a frequency transition, it does not make sense for it to bias > the schedutil's frequency selection policy. > > This patch exploits the information related to the current task to silently > ignore cpufreq_update_this_cpu() calls, coming from the RT scheduler, while > the sugov kthread is running. > > 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 > > --- > Changes from v1: > - move check before policy spinlock (JuriL) > --- > kernel/sched/cpufreq_schedutil.c | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c > index c982dd0..eaba6d6 100644 > --- a/kernel/sched/cpufreq_schedutil.c > +++ b/kernel/sched/cpufreq_schedutil.c > @@ -218,6 +218,10 @@ static void sugov_update_single(struct update_util_data *hook, u64 time, > unsigned int next_f; > bool busy; > > + /* Skip updates generated by sugov kthreads */ > + if (unlikely(current == sg_policy->thread)) > + return; > + > sugov_set_iowait_boost(sg_cpu, time, flags); > sg_cpu->last_update = time; > > @@ -290,6 +294,10 @@ static void sugov_update_shared(struct update_util_data *hook, u64 time, > unsigned long util, max; > unsigned int next_f; > > + /* Skip updates generated by sugov kthreads */ > + if (unlikely(current == sg_policy->thread)) > + return; > + This seems super race-y. Especially when combined with rate_limit_us. Deciding to not update the frequency for a policy just because the call back happened in the context of the kthread is not right. Especially when it's combined with the remote CPU call backs patches Viresh is putting out (which I think is a well intended patch series). -Saravana -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project