Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp412963ybi; Fri, 21 Jun 2019 01:44:03 -0700 (PDT) X-Google-Smtp-Source: APXvYqxq6iZVvT9Kp6/yEEa9xiGX3THlQngsiLJKdo6ZGghBzjIkEDRICe7T/nkv6SSM2mBn702J X-Received: by 2002:a63:10a:: with SMTP id 10mr12827069pgb.263.1561106642980; Fri, 21 Jun 2019 01:44:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561106642; cv=none; d=google.com; s=arc-20160816; b=K1RZwbJVTrUBQp5weiU+SRxFkHIQ3Xae3LaOC8HWsr8vlvPTIkwWyWKs2HI6ARvGgw nHO8m7Xx37zE8ySo9Ubi0Yyi3bOCAs1Yhh2sRQFuDrWxlDwDaGLC8Ax9MSAAbRmD4Ym3 JJtTJ/S5vF0w/wd4PDOa+0Me/16EBpgmGhhTFx7NwGLWuyz7TQ5zyTwcXmQIP1Aq5XAA gvm8yVbjIHUd2cQKeu0YDRJzHBFagA0HTcNWlu9Gb7NCQl3PEyuyQcOkIe3i7gPph1/A PDOQ0UgwESIOUSM0yBcFYtFjsXUrRNtPsHczBkgN7R09tw3v88p0XLNEaFYOgTl9f2oP dqAg== 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=j9ObtpUUSqTTdQprujMnahABxtaIUpce7/SiEoNutZs=; b=fpqbHrepM28NEdIQVgy7rpfad0xV7JbzyBsZ689Yfa9rd7VysQ9xPXqvxS22Jey/1v eaX2D+YF2VcHNuUNt1+maPgumDX8tUq2+qNiWqQfglGbF7s72MecTCgic28LqWVdicg2 wqJKs4IvfI9I93XKfQHBXGfEtnEXell70kXgvYRvfbfxJpUSuFlwbXd82UG3RP0bXU5D HrQQT46e3lu+uiEjtHUeKnYIbzEzXVed6LnUfp/BSvxtFmGhaygMaMidBwg2JbdDDexw I2FGgJIOoxvuGZDmYye3znO1twUUXPhWzvM25JuIefk+Y16LxiDg7sZWl1lljHWBgRxP A1Ww== 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 o11si2058136plk.47.2019.06.21.01.43.47; Fri, 21 Jun 2019 01:44:02 -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 S1726779AbfFUInP (ORCPT + 99 others); Fri, 21 Jun 2019 04:43:15 -0400 Received: from foss.arm.com ([217.140.110.172]:51092 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726755AbfFUInL (ORCPT ); Fri, 21 Jun 2019 04:43:11 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id EFAEF1597; Fri, 21 Jun 2019 01:43:10 -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 9CE983F246; Fri, 21 Jun 2019 01:43:08 -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 , Alessio Balsini Subject: [PATCH v10 14/16] sched/core: uclamp: Propagate system defaults to root group Date: Fri, 21 Jun 2019 09:42:15 +0100 Message-Id: <20190621084217.8167-15-patrick.bellasi@arm.com> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190621084217.8167-1-patrick.bellasi@arm.com> References: <20190621084217.8167-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 The clamp values are not tunable at the level of the root task group. That's for two main reasons: - the root group represents "system resources" which are always entirely available from the cgroup standpoint. - when tuning/restricting "system resources" makes sense, tuning must be done using a system wide API which should also be available when control groups are not. When a system wide restriction is available, cgroups should be aware of its value in order to know exactly how much "system resources" are available for the subgroups. Utilization clamping supports already the concepts of: - system defaults: which define the maximum possible clamp values usable by tasks. - effective clamps: which allows a parent cgroup to constraint (maybe temporarily) its descendants without losing the information related to the values "requested" from them. Exploit these two concepts and bind them together in such a way that, whenever system default are tuned, the new values are propagated to (possibly) restrict or relax the "effective" value of nested cgroups. Signed-off-by: Patrick Bellasi Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Tejun Heo --- kernel/sched/core.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 2b4d0b9bd6b9..f09712f65017 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -1006,6 +1006,13 @@ static inline void uclamp_rq_dec(struct rq *rq, struct task_struct *p) uclamp_rq_dec_id(rq, p, clamp_id); } +#ifdef CONFIG_UCLAMP_TASK_GROUP +static void cpu_util_update_eff(struct cgroup_subsys_state *css, + unsigned int clamp_id); +#else +#define cpu_util_update_eff(...) +#endif + int sysctl_sched_uclamp_handler(struct ctl_table *table, int write, void __user *buffer, size_t *lenp, loff_t *ppos) @@ -1039,6 +1046,9 @@ int sysctl_sched_uclamp_handler(struct ctl_table *table, int write, sysctl_sched_uclamp_util_max, false); } + cpu_util_update_eff(&root_task_group.css, UCLAMP_MIN); + cpu_util_update_eff(&root_task_group.css, UCLAMP_MAX); + /* * Updating all the RUNNABLE task is expensive, keep it simple and do * just a lazy update at each next enqueue time. -- 2.21.0