Received: by 10.223.176.5 with SMTP id f5csp420229wra; Wed, 7 Feb 2018 01:21:39 -0800 (PST) X-Google-Smtp-Source: AH8x225mxnStMaHUYZkQV6rcIDIKSOArCa8O93AjEq7UHhBylGfEzo+pvEnIrz+eLF0sV16sAPp+ X-Received: by 2002:a17:902:2f41:: with SMTP id s59-v6mr5574184plb.422.1517995299019; Wed, 07 Feb 2018 01:21:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517995298; cv=none; d=google.com; s=arc-20160816; b=kdjqpiO8EHpPFaVwNUQARsYjv1UnIC+k215grTMDeLr7UErsd70w/mhrhaKYjuUCEc TqmqMleTMayY002ozKY/LPB19D70h0IbREZkTtt/exmuynXiHSuATAoKbMrLGD3r4PAA OVq+IMrvrlIz0W+27KL20UWwJtLS3TqtacbL1W8OcoMDqAbGR2hnNj49tgDWRAo4tkhy 6m7cmQ78T29Jwa2TgSrEWeJNHcD3gtH+fjmbse3+c8fwqErFVWxosgHrmEFAYqebOvvh N7QPDLhONK9tURM1a7ebzhCMn4zijIcOaZV1Yzwc6f9DyXm5UyUs6hGymF8VgKOP3xQX Fklg== 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=ig/fgvm4zHXZBxJxgIJULQpcuQ9+8OnlIDzshkTwZcw=; b=zqZIgOzcuALpYBtwQ/kAFbPKva68QUHo44p4lsgnJqyQ4JXKRpe1nMrhod4gleXU/y O7prxT5ejespxq8NAM+dlomBi38OIq3vFyjIiogvjXLGkqRLT7PWs7QgDcJsFuZyBA4+ HohdBlieiv6AIL0tDsCUypzjr4XqUvCxU2VZm09Rttoes7cdxMQtcSPR6mjWiLA0tmbZ IxMTZhIDdR1AoBxtGpxklMWIvK+g90nCa63zt0lxT/igMLbsZ1OwcU1OgqBv4SOcIY8J KzMMCWJffXmKelx0hqTmaG+iypzEg8IgVl7CGEue0DOb55/GJbdsZW5W9QJmZftkFiZ+ tfrQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=YB8FaRHH; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e8si693252pgp.4.2018.02.07.01.21.24; Wed, 07 Feb 2018 01:21:38 -0800 (PST) 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=fail header.i=@gmail.com header.s=20161025 header.b=YB8FaRHH; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753762AbeBGJTH (ORCPT + 99 others); Wed, 7 Feb 2018 04:19:07 -0500 Received: from mail-ot0-f194.google.com ([74.125.82.194]:44296 "EHLO mail-ot0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753736AbeBGJTE (ORCPT ); Wed, 7 Feb 2018 04:19:04 -0500 Received: by mail-ot0-f194.google.com with SMTP id l5so146930otj.11; Wed, 07 Feb 2018 01:19:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ig/fgvm4zHXZBxJxgIJULQpcuQ9+8OnlIDzshkTwZcw=; b=YB8FaRHHa5XKWlZVJmwzY+V5UybpX11CFM6LW/Zf3INpOMNkITBjFDGYCqo7zrlA3T dWawS9SfhCptB0PZ8gQnhoep1P8XXI/k6RSGAN6FrcZzfVauZOyyu/RdnFBIk7i+0oN+ NQZ5YTSBktTkInQKY5oQcaCXQGvckCbsej9FEz7z4Yl90u88JvdX9yKAnmQwjuxVbHvO /OO8MqRyxdeHm7gKDO0W+Q7/kDYLSd9rAf5lf4qvfpL9Z3HFqlHNlazzC/BhDmf78ALd DMLM7hoCxfTE2dNaBaJODhHkid54ESo6de8+ESmaNimiEFS2fP+RyVGE3J0ATu6WT6Uo 4EFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ig/fgvm4zHXZBxJxgIJULQpcuQ9+8OnlIDzshkTwZcw=; b=SLExO52onHQXcP6IKQ5xCKgIxadPfuaINpZlMgXp+Hkp9LXLcFqtwTP67hWT9a9lX5 EihNzWYuwaGeuJ6EB05Ud6rvNFI3DKitvr9Ijk537djAHzqG1bS8oVzTjpR5C/oeNYOK k068i2UBp2cT8u5Jo3t3s8TASJPkXbhpw+uVpkudkK4DyPza5meXAjCxpS+UBzr4bDaT yIEppwtDKK/kupGJMz16TZD7NYR7W+uPOP9GM5cghTN6tccbUJS717daWBU/6XzkAOmy PpvdziX7RVSOXDEzPWXh5lgXWyd5PMFmz7ZBkXcH5SMt6gzquD+kwXIck8XDCNgWXSFP uocQ== X-Gm-Message-State: APf1xPC7O5C32F/xNNlawD+pSDHohFXqpJY9NE9R7R0yjNTbtyata9o+ ZZiE/owGLbQX6Y31XnAGumh2KUAcGMfL33O3/NM= X-Received: by 10.157.62.27 with SMTP id a27mr4370469otd.331.1517995143323; Wed, 07 Feb 2018 01:19:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.46.234 with HTTP; Wed, 7 Feb 2018 01:19:03 -0800 (PST) In-Reply-To: <20180206144131.31233-4-patrick.bellasi@arm.com> References: <20180206144131.31233-1-patrick.bellasi@arm.com> <20180206144131.31233-4-patrick.bellasi@arm.com> From: "Rafael J. Wysocki" Date: Wed, 7 Feb 2018 10:19:03 +0100 X-Google-Sender-Auth: y15ZA-njcxwigQd8Bt7jsfGA_wE Message-ID: Subject: Re: [PATCH v4 3/3] sched/cpufreq_schedutil: use util_est for OPP selection To: Patrick Bellasi Cc: Linux Kernel Mailing List , Linux PM , Ingo Molnar , Peter Zijlstra , "Rafael J . Wysocki" , Viresh Kumar , Vincent Guittot , Paul Turner , Dietmar Eggemann , Morten Rasmussen , Juri Lelli , Todd Kjos , 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 On Tue, Feb 6, 2018 at 3:41 PM, Patrick Bellasi wrote: > When schedutil looks at the CPU utilization, the current PELT value for > that CPU is returned straight away. In certain scenarios this can have > undesired side effects and delays on frequency selection. > > For example, since the task utilization is decayed at wakeup time, a > long sleeping big task newly enqueued does not add immediately a > significant contribution to the target CPU. This introduces some latency > before schedutil will be able to detect the best frequency required by > that task. > > Moreover, the PELT signal build-up time is a function of the current > frequency, because of the scale invariant load tracking support. Thus, > starting from a lower frequency, the utilization build-up time will > increase even more and further delays the selection of the actual > frequency which better serves the task requirements. > > In order to reduce this kind of latencies, we integrate the usage > of the CPU's estimated utilization in the sugov_get_util function. > This allows to properly consider the expected utilization of a CPU which, > for example, has just got a big task running after a long sleep period. > Ultimately this allows to select the best frequency to run a task > right after its wake-up. > > Signed-off-by: Patrick Bellasi > Reviewed-by: Dietmar Eggemann > Cc: Ingo Molnar > Cc: Peter Zijlstra > Cc: Rafael J. Wysocki > Cc: Viresh Kumar > Cc: Paul Turner > Cc: Vincent Guittot > Cc: Morten Rasmussen > Cc: Dietmar Eggemann > Cc: linux-kernel@vger.kernel.org > Cc: linux-pm@vger.kernel.org Acked-by: Rafael J. Wysocki > --- > Changes in v4: > - rebased on today's tip/sched/core (commit 460e8c3340a2) > - use util_est.enqueued for cfs_rq's util_est (Joel) > - simplify cpu_util_cfs() integration (Dietmar) > > Changes in v3: > - rebase on today's tip/sched/core (commit 07881166a892) > - moved into Juri's cpu_util_cfs(), which should also > address Rafael's suggestion to use a local variable. > > Changes in v2: > - rebase on top of v4.15-rc2 > - tested that overhauled PELT code does not affect the util_est > > Change-Id: I62c01ed90d8ad45b06383be03d39fcf8c9041646 > --- > kernel/sched/sched.h | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h > index 2e95505e23c6..f3c7b6a83ef4 100644 > --- a/kernel/sched/sched.h > +++ b/kernel/sched/sched.h > @@ -2127,7 +2127,12 @@ static inline unsigned long cpu_util_dl(struct rq *rq) > > static inline unsigned long cpu_util_cfs(struct rq *rq) > { > - return rq->cfs.avg.util_avg; > + if (!sched_feat(UTIL_EST)) > + return rq->cfs.avg.util_avg; > + > + return max_t(unsigned long, > + rq->cfs.avg.util_avg, > + rq->cfs.avg.util_est.enqueued); > } > > #endif > -- > 2.15.1 >