Received: by 10.223.176.46 with SMTP id f43csp4498371wra; Tue, 23 Jan 2018 10:10:03 -0800 (PST) X-Google-Smtp-Source: AH8x227FcCWma4qRYuw5JqWSJuEcwqCzIO2fDTxIxPwWJ8fLr5EoY7DDXIUwj9oZjfoVGwUUnowc X-Received: by 10.157.54.100 with SMTP id w91mr7926505otb.136.1516731003007; Tue, 23 Jan 2018 10:10:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516731002; cv=none; d=google.com; s=arc-20160816; b=EFt+GMRk3RYpdYzdHB5DvZ6+shV+fYHaSQagyxEXIm28s128TM9b0ghabCeHOnijMX v3eHSM7ytUA/6Pgh2fNc6fCBu7U41ZKHv06pCYEbGL/nsyc5J+QE9EXVLHbq6t9D/jWO I2ahbm2vPMYdCnk2VQr9UgGqTkjxO3qyLRksn29H6q2ho+NmJJfxbSxhhegXnveCSEDg 5LSaLZK8xqPtLpIg4GBCtOxHUJVf4nL4zUXwZjmf7Kxoq9KDzKt1sj/Dllu/WbRx5drV +1Pnhzkm33dyvO58EisquCEaZQtf7i9seLC6uVm0o/Tcz4B+eL3BRB99mdGcbl9phLf0 qV1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:arc-authentication-results; bh=zYZfO4gt6GxHV6JyRK37rQAqSXiEnkt7zxiMKo5vHHU=; b=Fd5lgkDtHA/NMBETKC5x+EsJMCSdhfWxh3x2pHIKyFyy0N0jszSxTG0SKJAYzcBhOg Ae0kwc1frFpFn6aUi4Pu3g3xkbQ89MXHHf6lfkSxJNnawxQYvkBXFYWluR2G8L0FBbOs UfK8+EqH7Wt1TXzLSRyXHBRckkCtYylFboJAlGtRZ23dD0sFJnctDsJujxP+8Czct5oP bO7f4tD/5MI0mOv8gN85tPcSp7/nw71E/w6zdxgra0AGqaITtDOqQFwLHt/+xUigmlvh MxjeXxfUf3F9N7in0ywyWQPSN1PiTwxYY/6RnimYtdlYOoLV2TwwK38YA8gjYMpCsL29 vqqA== ARC-Authentication-Results: i=1; mx.google.com; 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 w16si8805649ita.32.2018.01.23.10.09.49; Tue, 23 Jan 2018 10:10:02 -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; 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 S1752141AbeAWSJ1 (ORCPT + 99 others); Tue, 23 Jan 2018 13:09:27 -0500 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:45190 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751979AbeAWSJZ (ORCPT ); Tue, 23 Jan 2018 13:09:25 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id BBE1F1610; Tue, 23 Jan 2018 10:09:24 -0800 (PST) Received: from e110439-lin.cambridge.arm.com (e110439-lin.cambridge.arm.com [10.1.210.68]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 3E9F43F53D; Tue, 23 Jan 2018 10:09:22 -0800 (PST) From: Patrick Bellasi To: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org Cc: 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 Subject: [PATCH v3 3/3] sched/cpufreq_schedutil: use util_est for OPP selection Date: Tue, 23 Jan 2018 18:08:47 +0000 Message-Id: <20180123180847.4477-4-patrick.bellasi@arm.com> X-Mailer: git-send-email 2.15.1 In-Reply-To: <20180123180847.4477-1-patrick.bellasi@arm.com> References: <20180123180847.4477-1-patrick.bellasi@arm.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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, here we integrates 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 --- 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 --- 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 0b4d9750a927..08a80ee8f89e 100644 --- a/kernel/sched/sched.h +++ b/kernel/sched/sched.h @@ -2128,7 +2128,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; + unsigned long util_est = rq->cfs.avg.util_avg; + + if (sched_feat(UTIL_EST)) + util_est = max(util_est, rq->cfs.util_est_runnable); + + return util_est; } #endif -- 2.15.1