Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp4084216imm; Mon, 14 May 2018 02:17:08 -0700 (PDT) X-Google-Smtp-Source: AB8JxZr7B9+vvO5Z68bxhNmgoFnGnzIDzuVC70xWohW+8xTd26BUa9vv3MNp3WsjVC4XvROKnWiu X-Received: by 2002:a17:902:b184:: with SMTP id s4-v6mr8818786plr.359.1526289428618; Mon, 14 May 2018 02:17:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526289428; cv=none; d=google.com; s=arc-20160816; b=Ompho56hLnucrCNdeajBQOvEy7+Mr0HpTHWnM9SK4Lg1Q0rC2x3sfxwI0KzSK7NKWT B4MIeVjngleXnRBq8G2QWEAzDc3g5yy3khwv6/vbgvHf/0H4lWBd2dG9hlHP9a66PjMq 9fa3ToctVW/qRnvz3CoK4GDiGKpoI52LruSI1deQNvzWPYgr+vY8hNwpkCEl2oIHNT6U dl/UNFVJJk4I2GO2oT6K/vWmI+rTWuqn2HxXApgH65VEr+PRESbWULF8dgNZ9wu55xVc UrLVUnpEoA3LLNNWpf6QYDdF1vfEoc4/An/9uKuT/OUcgJJUUCLPWFq+NbB8CjCCFhf6 eEog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=qpR+ces1/m1tX9U8+ENjz8z+SqE1/3oj9irPlQ1arXo=; b=gzeA6vFCaNtsBpar6KX/G0jdAyRd/gER6TVDAi4qP22XeRvL07oAWYqA+BWn3OKIEn 9kvKo862YhgcXbcFPoPNyllrsNhoGd3qU8t4yFy2Dl9SpRsDmx+iuyIJFnad0WNANaxo uKI1vL/1b2uSH6g2P/9UvJLuAh/6ybByfnIHmNX30U+QrrgJJ41kdT7b283HerbJRk8z wx6HPgkCy5srpaKLEiOPkucEMMZZmN5wi7QfRmBm60xrKCL3QKwtvVhr1PVvQwMKg2uc 3HIQ28bPBu+IaWW4frFWkqZgxipTI3BbTkTwTdD53qcH7UoqVe/kO4Xbba7lPuHaClEa e8aA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=kd6trn3h; 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 p2-v6si7388253pgn.453.2018.05.14.02.16.53; Mon, 14 May 2018 02:17:08 -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=kd6trn3h; 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 S1752165AbeENJQf (ORCPT + 99 others); Mon, 14 May 2018 05:16:35 -0400 Received: from mail-io0-f194.google.com ([209.85.223.194]:40669 "EHLO mail-io0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751626AbeENJQd (ORCPT ); Mon, 14 May 2018 05:16:33 -0400 Received: by mail-io0-f194.google.com with SMTP id g14-v6so14343763ioc.7 for ; Mon, 14 May 2018 02:16:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qpR+ces1/m1tX9U8+ENjz8z+SqE1/3oj9irPlQ1arXo=; b=kd6trn3hZbC3L70uAqb3gPyNIB0OMCTE2tRix3sjxPi59CJe9ReP/XAklq9aQHKOOz xz2tZyB63I+by8fhZwE8kL3Zjbm5hqTAkHEkAdu2hRvGVcrFCTptuT28G6vPu0vCYvL5 JzWirsrOK2ku1VsZhshIsEI9zI557TgKz4kfE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qpR+ces1/m1tX9U8+ENjz8z+SqE1/3oj9irPlQ1arXo=; b=ODFel/zuF7OejBpv0aLQJRBhY8RrlYIi2vQ3zSikmFU6l9qS3+j+xc7N4Ytd868YZP vr6pp1n/nMd0qrTjdfBqRrFaypH0Le/sp3u4XZrqlk4WKdgnR4JecxSjtUfQrVmAROPF LK1dD+oqCwTjTfTeuJtEBUJw5IZ4KF9BEgr/zYs9RCRKPU2mMnb7O1+7UngT4c0dTWiE iuKicS4Dp0xanHm80jxmTpfMHE2bqTX0+YWMoJX+bXxQYN7x2L2um4BhVWC7Ev0Q8RjR NdiSSbFH97B256VGY2Wb5H8ipq9gdl5Qwg6aIwiRTb+FqI2G/iAmLgAQzZdQmCnCbNUD 4FNQ== X-Gm-Message-State: ALKqPwdIPX72AiFyopbeL+TvDw9QUUuwuzhqBxKT7gMa0a7EkQFeXxKW 8FVF64uiP8cUP25Zy7dY7d61MGNl5C/SgpTrh/brKg== X-Received: by 2002:a6b:2c9:: with SMTP id 192-v6mr9337364ioc.294.1526289392881; Mon, 14 May 2018 02:16:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.4.204 with HTTP; Mon, 14 May 2018 02:16:12 -0700 (PDT) In-Reply-To: <20180511131509.16275-2-patrick.bellasi@arm.com> References: <20180511131509.16275-1-patrick.bellasi@arm.com> <20180511131509.16275-2-patrick.bellasi@arm.com> From: Vincent Guittot Date: Mon, 14 May 2018 11:16:12 +0200 Message-ID: Subject: Re: [PATCH v2 1/3] sched/cpufreq: always consider blocked FAIR utilization To: Patrick Bellasi Cc: linux-kernel , "open list:THERMAL" , Ingo Molnar , Peter Zijlstra , "Rafael J . Wysocki" , Viresh Kumar , Dietmar Eggemann , Morten Rasmussen , Juri Lelli , Joel Fernandes , Steve Muckle Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Patrick, On 11 May 2018 at 15:15, 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 > Acked-by: Viresh Kumar > 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 With this patch, I can't see the spurious OPP changes that I was seeing before FWIW Acked-by: Vincent Guittot Tested-by: Vincent Guittot Regards, Vincent > > --- > > Changes in v2: > - add "Acked-by" Viresh tag > --- > kernel/sched/cpufreq_schedutil.c | 17 ++++++++--------- > 1 file changed, 8 insertions(+), 9 deletions(-) > > 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) > -- > 2.15.1 >