Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp3740839imd; Mon, 29 Oct 2018 11:36:01 -0700 (PDT) X-Google-Smtp-Source: AJdET5fM/H5cay3hrQjVVNzelhFa45XU2VcZLG/nDn6WM96C1dywiCjBEFS6vkJDY4kj2DvEtvqd X-Received: by 2002:a17:902:4624:: with SMTP id o33-v6mr15626172pld.285.1540838161151; Mon, 29 Oct 2018 11:36:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540838161; cv=none; d=google.com; s=arc-20160816; b=eVW0kgwaHHSeX2rjbpASeBn1S7w89yVHtrNaQwbSGk6ByP5HJOOFCc4BAU508OOoRe OdeLcJr5JnZzFTM+DFsEcEYOzwv6D3ROeQHFdtOii0hG9DdeGZ5kqmm27Q4ZDDPrUIyH VPU/cyI7Eom+/fBQa1BpXZa09IJ2RUQLlR4ySiOpypgUIxZKqOVbEBn7v8RccynSrFhS bjsmIoUNgPdoEBll/gbyvkJCnsCQcrC62t801HxDjd6AmzSKjIaLXleQDwW81mVXf9/9 iDJdeuRFOHTNAWqgMTOQz+8j8cLmnvGeGFj0H13IQ2ZNawGjX0aQvisJRRl5RK2z6iTH Xuiw== 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; bh=0SPdnXw8P9ah/XwcrdEawOj2tkOkOnJNG9hQiL7KUR4=; b=dT595OXu/rYzYtxeVJY5OFexFhgcAfusByQMM7Wv0wirJ1L7KlPZ4CB5b63hZXEz42 Bg5CE13CvCQaIoGIugbhoAznAtgElrKNIeHb/zf1FDHKMwnWUfBlamDVqVPUqb3cOYvb hSrXOsV5sfmY0DtzWzJ0YzXNF1is17zWo5GBZQICp8dfitrPZHX4TNnO51dMdzq2sKaO hCkiszXG2oW0181V5yeKr7X0N6WK1CsZV+NZ2JIsV1cQsJIvIHDKxzkAwQRrX3Uo6vXc IzUpOSiBhwmGu9iRkPcDakbpQArCZuEgn7vxwcnwYRs7ThQDIjqSeyE5TK3qF3uDXt3m d90A== 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 y2-v6si21497888pgc.430.2018.10.29.11.35.45; Mon, 29 Oct 2018 11:36:01 -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 S1729580AbeJ3DXx (ORCPT + 99 others); Mon, 29 Oct 2018 23:23:53 -0400 Received: from foss.arm.com ([217.140.101.70]:44666 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729275AbeJ3DXw (ORCPT ); Mon, 29 Oct 2018 23:23:52 -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 4CC2A341; Mon, 29 Oct 2018 11:34:01 -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 5BA843F6A8; Mon, 29 Oct 2018 11:33:58 -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" , Vincent Guittot , Viresh Kumar , Paul Turner , Quentin Perret , Dietmar Eggemann , Morten Rasmussen , Juri Lelli , Todd Kjos , Joel Fernandes , Steve Muckle , Suren Baghdasaryan Subject: [PATCH v5 09/15] sched/cpufreq: uclamp: add utilization clamping for FAIR tasks Date: Mon, 29 Oct 2018 18:33:04 +0000 Message-Id: <20181029183311.29175-11-patrick.bellasi@arm.com> X-Mailer: git-send-email 2.18.0 In-Reply-To: <20181029183311.29175-1-patrick.bellasi@arm.com> References: <20181029183311.29175-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 userspace utilization clamping hints. This will allow, for example, to: - boost tasks which are directly affecting the user experience by running them at least at a minimum "requested" 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 frequency selection thus supporting a fine grained definition of performance boosting vs energy saving strategies in kernel space. This adds the required support to clamp the utilization generated by RUNNABLE 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 and the IOWait boost 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: Suren Baghdasaryan Cc: Todd Kjos Cc: Joel Fernandes Cc: Juri Lelli Cc: Quentin Perret Cc: Dietmar Eggemann Cc: Morten Rasmussen Cc: linux-kernel@vger.kernel.org Cc: linux-pm@vger.kernel.org --- Changes in v5: Message-ID: <20180914133654.GL24124@hirez.programming.kicks-ass.net> - add a comment to justify the assumptions on util clamping for FAIR tasks Message-ID: <20180914093240.GB24082@hirez.programming.kicks-ass.net> - removed uclamp_value and use inline access to data structures Message-ID: <20180914135712.GQ1413@e110439-lin> - the (unlikely(val == UCLAMP_NOT_VALID)) check is not more required since we now ensure we always have a valid value configured Others: - rebased on v4.19 Changes in v4: Message-ID: - use *rq instead of cpu for both uclamp_util() and uclamp_value() Message-ID: <20180816135300.GC2960@e110439-lin> - remove uclamp_value() which is never used outside CONFIG_UCLAMP_TASK Others: - rebased on v4.19-rc1 Changes in v3: Message-ID: - rename UCLAMP_NONE into UCLAMP_NOT_VALID Others: - rebased on tip/sched/core Changes in v2: - rebased on v4.18-rc4 --- kernel/sched/cpufreq_schedutil.c | 25 ++++++++++++++++++++++--- kernel/sched/sched.h | 28 ++++++++++++++++++++++++++++ 2 files changed, 50 insertions(+), 3 deletions(-) diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c index 3fffad3bc8a8..fd3fe55d605b 100644 --- a/kernel/sched/cpufreq_schedutil.c +++ b/kernel/sched/cpufreq_schedutil.c @@ -222,8 +222,13 @@ static unsigned long sugov_get_util(struct sugov_cpu *sg_cpu) * CFS tasks and we use the same metric to track the effective * utilization (PELT windows are synchronized) we can directly add them * to obtain the CPU's actual utilization. + * + * CFS utilization can be boosted or capped, depending on utilization + * clamp constraints requested by currently RUNNABLE tasks. + * When there are no CFS RUNNABLE tasks, clamps are released and OPPs + * will be gracefully reduced with the utilization decay. */ - util = cpu_util_cfs(rq); + util = uclamp_util(rq, cpu_util_cfs(rq)); util += cpu_util_rt(rq); /* @@ -307,6 +312,7 @@ static void sugov_iowait_boost(struct sugov_cpu *sg_cpu, u64 time, unsigned int flags) { bool set_iowait_boost = flags & SCHED_CPUFREQ_IOWAIT; + unsigned int max_boost; /* Reset boost if the CPU appears to have been idle enough */ if (sg_cpu->iowait_boost && @@ -322,11 +328,24 @@ static void sugov_iowait_boost(struct sugov_cpu *sg_cpu, u64 time, return; sg_cpu->iowait_boost_pending = true; + /* + * Boost FAIR tasks only up to the 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 RT tasks are not utiliation clamped, we don't want + * to apply clamping on IO boost while there is blocked RT + * utilization. + */ + max_boost = sg_cpu->iowait_boost_max; + if (!cpu_util_rt(cpu_rq(sg_cpu->cpu))) + max_boost = uclamp_util(cpu_rq(sg_cpu->cpu), max_boost); + /* Double the boost at each request */ 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; + if (sg_cpu->iowait_boost > max_boost) + sg_cpu->iowait_boost = max_boost; return; } diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h index 859192ec492c..a7e9b7041ea5 100644 --- a/kernel/sched/sched.h +++ b/kernel/sched/sched.h @@ -2262,6 +2262,34 @@ static inline unsigned int uclamp_none(int clamp_id) return SCHED_CAPACITY_SCALE; } +#ifdef CONFIG_UCLAMP_TASK +/** + * clamp_util: clamp a utilization value for a specified CPU + * @rq: the CPU's RQ 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 RUNNABLE 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(struct rq *rq, unsigned int util) +{ + unsigned int min_util = rq->uclamp.value[UCLAMP_MIN]; + unsigned int max_util = rq->uclamp.value[UCLAMP_MAX]; + + return clamp(util, min_util, max_util); +} +#else /* CONFIG_UCLAMP_TASK */ +static inline unsigned int uclamp_util(struct rq *rq, 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.18.0