Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp370442imm; Thu, 10 May 2018 22:46:03 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpCFpJQ8zgURAs5tuA0dRJ0xNGfPcoyZ9wsylka1qg5dWYwYnw14AMUyPPGdAm4QFraxG0P X-Received: by 2002:a17:902:14d:: with SMTP id 71-v6mr4119953plb.275.1526017563716; Thu, 10 May 2018 22:46:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526017563; cv=none; d=google.com; s=arc-20160816; b=EsRP3hqjveuYMgvTZPVYVmP7VCj0VWMoB+kZ9jAA0VOkTcsu+QfCDpWI8npPxviYlp I8aaI/z9kxkyaH4XIMhwF8CskRaEklKGw+xq5LP4jKZuQpWqSKfOxbAIcACT9ct+NYrL cRJj71sYXukZTxG0T8NWDMP9RdsWG3cXlkvs1ULAzZ9MD/XG1B4a4kdifJ72I9IZala8 W5zOqpMpas/uAhtdvwyVoVPadW21KEMJaAxJhSxOj7ps6uwPt1JBD1wruZoa2wcFxcT0 Db82BSe9uZG1gKJWEd+0SDAYLPFx9uddWtfx/uYnVEsdpkR86hnlPUsDM3GnHzknO+Ie IbCQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=KmpFCLdFvXciZ77ii52/PX/QFeU3kO6LOjVovMt847E=; b=oXlVucItCG3o+46CEiLZ5HliDsberXdSKdEh9x2ADdlmO5j/AWcn4ATuNBmq0/FVAD ZE1KvHChonyXQkn/pgTWGP3qlOgE2mdXIiCFKHOd+c5OH0lrB8tsWT3roGs06+XYnZxy V7UsejQRse/xzBztKB8+4yLkw3kovWZWlL0RWEgL8STW0urJqXICqoMKqYe0weke9eyi Vjh4cRESHwOW10dHxrV9HJajx8fpz8S8yJRCCRr7xu1EbHxq4GuepSr8x+iQN1xVX+Ja PHnWAhDOADEBj/rZyztIuMGK+E6YvfMIc7g0RWnzpFWtXaR+QjgBIJmJZ9boLpFhuZrI fi/A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=jUp/v0Ix; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u15-v6si2033948pgc.383.2018.05.10.22.45.49; Thu, 10 May 2018 22:46:03 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=jUp/v0Ix; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752428AbeEKFoN (ORCPT + 99 others); Fri, 11 May 2018 01:44:13 -0400 Received: from mail-pg0-f68.google.com ([74.125.83.68]:43911 "EHLO mail-pg0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752007AbeEKFoL (ORCPT ); Fri, 11 May 2018 01:44:11 -0400 Received: by mail-pg0-f68.google.com with SMTP id k11-v6so1962360pgo.10 for ; Thu, 10 May 2018 22:44:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=KmpFCLdFvXciZ77ii52/PX/QFeU3kO6LOjVovMt847E=; b=jUp/v0IxTI/gq5HsgXFY+TBCDbppmCZEtMJhdKD9pECE/OcKXSjWf8RE3ppIoOpBhj rjNKIgif+wmxJIViv9dRDwftkTazfFrHPt60xCDMHgcP4NgPMlNYN56DqbcRQuUv22zz OJ29ZiSthdOsTMLlGbXL3AGvnDcMuR+UJong0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=KmpFCLdFvXciZ77ii52/PX/QFeU3kO6LOjVovMt847E=; b=LphIlGtuoYf54+NyFGdeRI+UhYYHWxLKMrWkDxEiwdVEpnzkWvgAGZqG8ImPvOUVTd lmNh5+/qoQeXmtP/HPQZI/lWUv1vM+XV85hmkS3ZHgz0Tuqas+u7CuojCUIAksmwGICC 61OfliNtX76W6tL7h79nPLI31KYAS57hc+bC4/ZAo1TkGvFL/JvFqFl0SWpXhoLTr5/D O2aW9Hm6Bgv1uhQmwCbTDwdkf+Sbk2lAr6BMd7Vj87RM+B5s+Rh13N3ZHUvjywGaTv8F Tuhd3gKc3zRhg09ayAveLtERzcLfJMLBxX0cSq0JT9DQoByiA8eJ01LJS8M219yy0/BH f1Fg== X-Gm-Message-State: ALKqPwc6VuCrWAg/F5eLPqINeUissD62PH5KBS3+QDuWt7HAjftMMOT8 QLTzVdMdTvPIerj/NHcFrzhHjg== X-Received: by 2002:a65:5807:: with SMTP id g7-v6mr3319188pgr.409.1526017450551; Thu, 10 May 2018 22:44:10 -0700 (PDT) Received: from localhost ([122.167.163.112]) by smtp.gmail.com with ESMTPSA id i186-v6sm4063343pge.40.2018.05.10.22.44.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 May 2018 22:44:09 -0700 (PDT) Date: Fri, 11 May 2018 11:14:07 +0530 From: Viresh Kumar To: Patrick Bellasi Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, Ingo Molnar , Peter Zijlstra , "Rafael J . Wysocki" , Vincent Guittot , Dietmar Eggemann , Morten Rasmussen , Juri Lelli , Joel Fernandes , Steve Muckle Subject: Re: [PATCH 1/3] sched/cpufreq: always consider blocked FAIR utilization Message-ID: <20180511054407.qxwyyqsgyzqsf6e4@vireshk-i7> References: <20180510150553.28122-1-patrick.bellasi@arm.com> <20180510150553.28122-2-patrick.bellasi@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180510150553.28122-2-patrick.bellasi@arm.com> User-Agent: NeoMutt/20180323-120-3dd1ac Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10-05-18, 16:05, Patrick Bellasi wrote: > Since the refactoring introduced by: > > commit 8f111bc357aa ("cpufreq/schedutil: Rewrite CPUFREQ_RT support") > > we aggregate FAIR utilization only if this class has runnable tasks. > This was mainly due to avoid the risk to stay on an high frequency just > because of the blocked utilization of a CPU not being properly decayed > while the CPU was idle. > > However, since: > > commit 31e77c93e432 ("sched/fair: Update blocked load when newly idle") > > the FAIR blocked utilization is properly decayed also for IDLE CPUs. > > This allows us to use the FAIR blocked utilization as a safe mechanism > to gracefully reduce the frequency only if no FAIR tasks show up on a > CPU for a reasonable period of time. > > Moreover, we also reduce the frequency drops of CPUs running periodic > tasks which, depending on the task periodicity and the time required > for a frequency switch, was increasing the chances to introduce some > undesirable performance variations. > > Reported-by: Vincent Guittot > Signed-off-by: Patrick Bellasi > Cc: Ingo Molnar > Cc: Peter Zijlstra > Cc: Rafael J. Wysocki > Cc: Vincent Guittot > Cc: Viresh Kumar > Cc: Joel Fernandes > Cc: linux-kernel@vger.kernel.org > Cc: linux-pm@vger.kernel.org > --- > kernel/sched/cpufreq_schedutil.c | 17 ++++++++--------- > 1 file changed, 8 insertions(+), 9 deletions(-) Do we need a Fixes tag and Cc stable ? > > diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c > index d2c6083304b4..a74d05160e66 100644 > --- a/kernel/sched/cpufreq_schedutil.c > +++ b/kernel/sched/cpufreq_schedutil.c > @@ -183,22 +183,21 @@ static void sugov_get_util(struct sugov_cpu *sg_cpu) > static unsigned long sugov_aggregate_util(struct sugov_cpu *sg_cpu) > { > struct rq *rq = cpu_rq(sg_cpu->cpu); > - unsigned long util; > > - if (rq->rt.rt_nr_running) { > - util = sg_cpu->max; > - } else { > - util = sg_cpu->util_dl; > - if (rq->cfs.h_nr_running) > - util += sg_cpu->util_cfs; > - } > + if (rq->rt.rt_nr_running) > + return sg_cpu->max; > > /* > + * Utilization required by DEADLINE must always be granted while, for > + * FAIR, we use blocked utilization of IDLE CPUs as a mechanism to > + * gracefully reduce the frequency when no tasks show up for longer > + * periods of time. > + * > * Ideally we would like to set util_dl as min/guaranteed freq and > * util_cfs + util_dl as requested freq. However, cpufreq is not yet > * ready for such an interface. So, we only do the latter for now. > */ > - return min(util, sg_cpu->max); > + return min(sg_cpu->max, (sg_cpu->util_dl + sg_cpu->util_cfs)); > } > > static void sugov_set_iowait_boost(struct sugov_cpu *sg_cpu, u64 time, unsigned int flags) Acked-by: Viresh Kumar -- viresh