Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1164172yba; Tue, 2 Apr 2019 03:44:05 -0700 (PDT) X-Google-Smtp-Source: APXvYqzZ7PudWi5pJAHg2xj2LzZOFAguQTShvYlFNNovabl/DuL+xojRErluooEGPpr8hvDVK1cP X-Received: by 2002:a17:902:e20e:: with SMTP id ce14mr56297710plb.193.1554201845044; Tue, 02 Apr 2019 03:44:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554201845; cv=none; d=google.com; s=arc-20160816; b=MpA/Z0eHKY0XKPnTayIHHrE9wLUlrafrH8B1S0+I4vmqDCtHCFr3rarPZFnA6GRNut DM8aOuDi0qedfqfjTt0IdsklCXCQmv2WobnDZxk65+m7DtWpIQOupaoLb9P8dmkMF6sD Z12QpBcBsWCNTueGzu3GoJEE72j+NPZa0bVxJQUPOPArhWtfANl2ebXEwYAqikBpaTG7 JEpj8oF6tNETp578jq8AN6e0iHvBC+089PTlNxKoOE3ECKm29QNsYY0S3Rj6eHuVU7Yf 0CDX3oyaHUCjjt5hfTU+6zn0zWO35tAI9EIil2C4M6U61uCrFebCKxGVMRL2wuQeKvy4 6Sjw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=VvzUrWagBsethbvQHtfz+qvEIo6+VnUp5kpPmqT8Wjk=; b=nafW81yZrr8MxvsZvUoaY9+OpDE+ByUZIxMCLboEjJG7R46CSGoh4YWYu4VwAqBF0m 2OFiDJbyTrqyQLAT7+JevYQBlopc4L69Cadq/xbm0BNQ2RDHUHpaD4SXTomu/tltES0b F6OovNr2nRkFMtkapgRkGWU3JnghWgUV0OBOinF47VAzL9kXCiTs2Sb6sluAQQ73nuSl 6w8muNGB9jre64PCM95UwCq5wkbU/Vw3wH04fcjrCbxSbCkvgzfhdYmLiY6GW/Qnj7e4 r0iBsYA/reT3as3Mhg+Ui69tAERksoZp0kZFTSDfbnVNT6Zry1YaoKeHVB9MoUU9xVmy NPqQ== 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 gn6si11202621plb.167.2019.04.02.03.43.49; Tue, 02 Apr 2019 03:44:05 -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; 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 S1730261AbfDBKmy (ORCPT + 99 others); Tue, 2 Apr 2019 06:42:54 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:48438 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729935AbfDBKmv (ORCPT ); Tue, 2 Apr 2019 06:42:51 -0400 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 9A6701688; Tue, 2 Apr 2019 03:42:51 -0700 (PDT) Received: from e110439-lin.cambridge.arm.com (e110439-lin.cambridge.arm.com [10.1.194.43]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 833B33F59C; Tue, 2 Apr 2019 03:42:48 -0700 (PDT) From: Patrick Bellasi To: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-api@vger.kernel.org Cc: Ingo Molnar , Peter Zijlstra , Tejun Heo , "Rafael J . Wysocki" , Vincent Guittot , Viresh Kumar , Paul Turner , Quentin Perret , Dietmar Eggemann , Morten Rasmussen , Juri Lelli , Todd Kjos , Joel Fernandes , Steve Muckle , Suren Baghdasaryan Subject: [PATCH v8 10/16] sched/core: uclamp: Add uclamp_util_with() Date: Tue, 2 Apr 2019 11:41:46 +0100 Message-Id: <20190402104153.25404-11-patrick.bellasi@arm.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190402104153.25404-1-patrick.bellasi@arm.com> References: <20190402104153.25404-1-patrick.bellasi@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org So far uclamp_util() allows to clamp a specified utilization considering the clamp values requested by RUNNABLE tasks in a CPU. For the Energy Aware Scheduler (EAS) it is interesting to test how clamp values will change when a task is becoming RUNNABLE on a given CPU. For example, EAS is interested in comparing the energy impact of different scheduling decisions and the clamp values can play a role on that. Add uclamp_util_with() which allows to clamp a given utilization by considering the possible impact on CPU clamp values of a specified task. Signed-off-by: Patrick Bellasi Cc: Ingo Molnar Cc: Peter Zijlstra --- Changes in v8: Others: - s/uclamp_effective_value()/uclamp_eff_value()/ --- kernel/sched/sched.h | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h index b4c13f3beb2f..a1ed3d94652a 100644 --- a/kernel/sched/sched.h +++ b/kernel/sched/sched.h @@ -2276,11 +2276,20 @@ static inline void cpufreq_update_util(struct rq *rq, unsigned int flags) {} #endif /* CONFIG_CPU_FREQ */ #ifdef CONFIG_UCLAMP_TASK -static inline unsigned int uclamp_util(struct rq *rq, unsigned int util) +unsigned int uclamp_eff_value(struct task_struct *p, unsigned int clamp_id); + +static __always_inline +unsigned int uclamp_util_with(struct rq *rq, unsigned int util, + struct task_struct *p) { unsigned int min_util = READ_ONCE(rq->uclamp[UCLAMP_MIN].value); unsigned int max_util = READ_ONCE(rq->uclamp[UCLAMP_MAX].value); + if (p) { + min_util = max(min_util, uclamp_eff_value(p, UCLAMP_MIN)); + max_util = max(max_util, uclamp_eff_value(p, UCLAMP_MAX)); + } + /* * Since CPU's {min,max}_util clamps are MAX aggregated considering * RUNNABLE tasks with _different_ clamps, we can end up with an @@ -2291,7 +2300,17 @@ static inline unsigned int uclamp_util(struct rq *rq, unsigned int util) return clamp(util, min_util, max_util); } + +static inline unsigned int uclamp_util(struct rq *rq, unsigned int util) +{ + return uclamp_util_with(rq, util, NULL); +} #else /* CONFIG_UCLAMP_TASK */ +static inline unsigned int uclamp_util_with(struct rq *rq, unsigned int util, + struct task_struct *p) +{ + return util; +} static inline unsigned int uclamp_util(struct rq *rq, unsigned int util) { return util; -- 2.20.1