Received: by 10.213.65.68 with SMTP id h4csp2849882imn; Mon, 9 Apr 2018 10:00:56 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/Ik+iXrmp9LWddFvMDX6Om7b4VuhMx9dRIr5H3l9wfYJjXXOjaIXkvMzjQhoR/cOCDVab1 X-Received: by 10.99.101.66 with SMTP id z63mr15788328pgb.383.1523293256459; Mon, 09 Apr 2018 10:00:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523293256; cv=none; d=google.com; s=arc-20160816; b=L95X59Ch1nB/3d+Rm+wFhoyuGpKXM4Stcfq0np0mWdLjpBZqexi63RHthffMSxvSDY jAgv8MxQY9PEYIPPG3QekYsH6y/POVOgebx9r5CPZVz0b2uL0hWCfSv1Ats9HiCZy5kh i2AfX6rFdIsk++XaQ273AfMQtaA3I1y/MVFwPSHif49eeas1kZ8NpHGtnoo6Z+LukyQM AK0PrmwWJmWM65/vqaRPV4FDBjRH3XeCzGrAYe9irn1TcgpzyEygVoxwNaxHBH9U4U1q LnbOiNhyncbAEWajePHcfDk/gQbTNN9qVdhNJLq9GhHrBLzJaU1ixY9UMG7VvPlSaAaR VfIQ== 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=/djzGLUMNInW2dBkJrXdrjSXUJgMDwmdsn3Z2aXaQIA=; b=j0RABnQuMElTGBcQKW4sOfn7vkHAy/jfe8vJJ4vkhDj+4m2aNNgI1yVOlFpkR1QHNR 98EUq+OxoWerp70sEymm/V2Oj51VM9eVRTwj0KnZV3YQwJkhJDqNv2oA4dBET2GzLu0a OyJU6ncvtqNqVkmok3wBN6qCASlgIN4K3o6m1kq1xr2lhIC4dxF0VdailAwZmQgzPYAG mSM+iTPa+4FOAEvtQgMP2xCwK3Y+CCoc9NAQIPWCec6PR5cj6+eiv3d6PYvLx73m8FJa JcfaxB158T17amn2BVyva1+ARPGhhmtFemVD3TJ19wHjFyQcOuZ5xOyYme72QUdMNuIi wU3A== 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 s8-v6si683834plk.550.2018.04.09.10.00.19; Mon, 09 Apr 2018 10:00:56 -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 S1753920AbeDIQ5M (ORCPT + 99 others); Mon, 9 Apr 2018 12:57:12 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:58598 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753843AbeDIQ4s (ORCPT ); Mon, 9 Apr 2018 12:56:48 -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 52A7215B2; Mon, 9 Apr 2018 09:56:48 -0700 (PDT) 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 CCD153F24A; Mon, 9 Apr 2018 09:56:45 -0700 (PDT) From: Patrick Bellasi To: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org Cc: Ingo Molnar , Peter Zijlstra , Tejun Heo , "Rafael J . Wysocki" , Viresh Kumar , Vincent Guittot , Paul Turner , Dietmar Eggemann , Morten Rasmussen , Juri Lelli , Joel Fernandes , Steve Muckle Subject: [PATCH 6/7] sched/cpufreq: uclamp: add utilization clamping for FAIR tasks Date: Mon, 9 Apr 2018 17:56:14 +0100 Message-Id: <20180409165615.2326-7-patrick.bellasi@arm.com> X-Mailer: git-send-email 2.15.1 In-Reply-To: <20180409165615.2326-1-patrick.bellasi@arm.com> References: <20180409165615.2326-1-patrick.bellasi@arm.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Each time a frequency update is required via schedutil, a frequency is selected to (possibly) satisfy the utilization reported by the CFS class. However, when utilization clamping is in use, the frequency selection should consider the requirements suggested by userspace, for example, to: - boost tasks which are directly affecting the user experience by running them at least at a minimum "required" frequency - cap low priority tasks not directly affecting the user experience by running them only up to a maximum "allowed" frequency These constraints are meant to support a per-task based tuning of the operating frequency selection thus allowing to have a fine grained definition of performance boosting vs energy saving strategies in kernel space. Let's add the required support to clamp the utilization generated by FAIR tasks within the boundaries defined by their aggregated utilization clamp constraints. On each CPU the aggregated clamp values are obtained by considering the maximum of the {min,max}_util values for each task. This max aggregation responds to the goal of not penalizing, for example, high boosted (i.e. more important for the user-experience) CFS tasks which happens to be co-scheduled with high capped (i.e. less important for the user-experience) CFS tasks. For FAIR tasks both the utilization as well as the IOWait boot values are clamped according to the CPU aggregated utilization clamp constraints. The default values for boosting and capping are defined to be: - util_min: 0 - util_max: SCHED_CAPACITY_SCALE which means that by default no boosting/capping is enforced on FAIR tasks, and thus the frequency will be selected considering the actual utilization value of each CPU. Signed-off-by: Patrick Bellasi Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Rafael J. Wysocki Cc: Viresh Kumar Cc: Joel Fernandes Cc: Juri Lelli Cc: Dietmar Eggemann Cc: Morten Rasmussen Cc: linux-kernel@vger.kernel.org Cc: linux-pm@vger.kernel.org --- kernel/sched/cpufreq_schedutil.c | 29 ++++++++++++++------ kernel/sched/sched.h | 59 ++++++++++++++++++++++++++++++++++++++++ 2 files changed, 80 insertions(+), 8 deletions(-) diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c index e021db562308..fe53984d06a0 100644 --- a/kernel/sched/cpufreq_schedutil.c +++ b/kernel/sched/cpufreq_schedutil.c @@ -190,7 +190,7 @@ static unsigned long sugov_aggregate_util(struct sugov_cpu *sg_cpu) } else { util = sg_cpu->util_dl; if (rq->cfs.h_nr_running) - util += sg_cpu->util_cfs; + util += uclamp_util(sg_cpu->cpu, sg_cpu->util_cfs); } /* @@ -213,6 +213,7 @@ static unsigned long sugov_aggregate_util(struct sugov_cpu *sg_cpu) */ static void sugov_set_iowait_boost(struct sugov_cpu *sg_cpu, unsigned int flags) { + unsigned int max_boost; /* Boost only tasks waking up after IO */ if (!(flags & SCHED_CPUFREQ_IOWAIT)) @@ -223,16 +224,28 @@ static void sugov_set_iowait_boost(struct sugov_cpu *sg_cpu, unsigned int flags) return; sg_cpu->iowait_boost_pending = true; - /* Double the IO boost at each frequency increase */ - if (sg_cpu->iowait_boost) { - sg_cpu->iowait_boost <<= 1; - if (sg_cpu->iowait_boost > sg_cpu->iowait_boost_max) - sg_cpu->iowait_boost = sg_cpu->iowait_boost_max; + /* At first wakeup after IO, start with minimum boost */ + if (!sg_cpu->iowait_boost) { + sg_cpu->iowait_boost = sg_cpu->sg_policy->policy->min; return; } - /* At first wakeup after IO, start with minimum boost */ - sg_cpu->iowait_boost = sg_cpu->sg_policy->policy->min; + /* + * Boost only up to the current max CPU clamped utilization. + * + * Since DL tasks have a much more advanced bandwidth control, it's + * safe to assume that IO boost does not apply to those tasks. + * Instead, since for RT tasks we are going to max, we don't want to + * clamp the IO boost max value. + */ + max_boost = sg_cpu->iowait_boost_max; + if (!cpu_rq(sg_cpu->cpu)->rt.rt_nr_running) + max_boost = uclamp_util(sg_cpu->cpu, max_boost); + + /* Double the IO boost at each frequency increase */ + sg_cpu->iowait_boost <<= 1; + if (sg_cpu->iowait_boost > max_boost) + sg_cpu->iowait_boost = max_boost; } /** diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h index a91b9cd162a3..1aa5d9b93fa5 100644 --- a/kernel/sched/sched.h +++ b/kernel/sched/sched.h @@ -2268,6 +2268,65 @@ static inline void cpufreq_update_util(struct rq *rq, unsigned int flags) static inline void cpufreq_update_util(struct rq *rq, unsigned int flags) {} #endif /* CONFIG_CPU_FREQ */ +#ifdef CONFIG_UCLAMP_TASK +/** + * uclamp_value: get the current CPU's utilization clamp value + * @cpu: the CPU to consider + * @clamp_id: the utilization clamp index (i.e. min or max utilization) + * + * The utilization clamp value for a CPU depends on its set of currently + * active tasks and their specific util_{min,max} constraints. + * A max aggregated value is tracked for each CPU and returned by this + * function. An IDLE CPU never enforces a clamp value. + * + * Return: the current value for the specified CPU and clamp index + */ +static inline unsigned int uclamp_value(unsigned int cpu, int clamp_id) +{ + struct uclamp_cpu *uc_cpu = &cpu_rq(cpu)->uclamp[clamp_id]; + int clamp_value = uclamp_none(clamp_id); + + /* Update min utilization clamp */ + if (uc_cpu->value != UCLAMP_NONE) + clamp_value = uc_cpu->value; + + return clamp_value; +} + +/** + * clamp_util: clamp a utilization value for a specified CPU + * @cpu: the CPU to get the clamp values from + * @util: the utilization signal to clamp + * + * Each CPU tracks util_{min,max} clamp values depending on the set of its + * currently active tasks. Given a utilization signal, i.e a signal in the + * [0..SCHED_CAPACITY_SCALE] range, this function returns a clamped + * utilization signal considering the current clamp values for the + * specified CPU. + * + * Return: a clamped utilization signal for a given CPU. + */ +static inline unsigned int uclamp_util(unsigned int cpu, unsigned int util) +{ + unsigned int min_util = uclamp_value(cpu, UCLAMP_MIN); + unsigned int max_util = uclamp_value(cpu, UCLAMP_MAX); + + return clamp(util, min_util, max_util); +} +#else /* CONFIG_UCLAMP_TASK */ +static inline unsigned int uclamp_value(unsigned int cpu, int clamp_id) +{ + if (clamp_id == UCLAMP_MIN) + return 0; + return SCHED_CAPACITY_SCALE; +} + +static inline unsigned int uclamp_util(unsigned int cpu, unsigned int util) +{ + return util; +} +#endif /* CONFIG_UCLAMP_TASK */ + #ifdef arch_scale_freq_capacity # ifndef arch_scale_freq_invariant # define arch_scale_freq_invariant() true -- 2.15.1