Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1164402yba; Tue, 2 Apr 2019 03:44:28 -0700 (PDT) X-Google-Smtp-Source: APXvYqyf1NW6eCQIO+Mb5ce9WTItMEkdxfZBRkYH6DWAiaS6EXyAbbeUqVrvotNq6mAbrau9Rn+L X-Received: by 2002:a63:5a1d:: with SMTP id o29mr61621346pgb.320.1554201868339; Tue, 02 Apr 2019 03:44:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554201868; cv=none; d=google.com; s=arc-20160816; b=z4t9k1UEybYi7JPFVFd3an25WBtrGIQ2z/lCbvMJ73cpZzd+tQmaWkwPHj2B/PTqWQ CUP2oc4X00egMmXQr+9UbdQK4x9TAjhVJWugX0Ql/WO0P+/yvbuhL3gqNfXUSXaFwjoE 91g4c4nKfwXHoFsNbK4Tji03Lzcg4wQlJs+1C8bhO4bsJoYy9E42MkgyDhGU7X9Kg5PP +YSklOg13g4sQxawXNcC9Kf6PFUuAASjcON33OOs9LD9qLd7gCd8rPIx61AvuBe7O9Re qXASzh4mP9BQM9sL+uzu9s2h0FSTXDXi38Q5Fw/MlJSeXZDx1PYCLdU1d0EO1dapIFSJ krog== 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=yq0bgX0MUOkmhoOse8ycg26RA/XVQVJNCCEhxbGIKj4=; b=zqGUVe1bnlNdtFbUcoCzR00IcDwWCT7DSJAHwaa3wEd4vZhiMU/VRLIpPtbtsVP1Sq p9NSfxV3iJamSg6QJA3QH2i85w0a8MLwAnVaOopS7IOTk2KUxm3Te8t92Gf9qqFZLDwK 4jbFy+jV+kGeJtPLxDqkcfWAOla7+cgZ4rkAh/u0oZiW2D8rQR/MP4aEzU1ztFRB5xHv aagiKZQcJL4J06f23JSP+jixNdv37IV36/0AwevUVdLixNjDOT+6tjHR8CnwOYyvYD7u rtepjwupHMh3W4up4kMOASy3N+XGa+sBIbunzeUohHp06uSRcR3XE2cc+lwCQ4TCZyGY SZgQ== 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 w10si10721662pgp.31.2019.04.02.03.44.12; Tue, 02 Apr 2019 03:44:28 -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 S1730401AbfDBKnJ (ORCPT + 99 others); Tue, 2 Apr 2019 06:43:09 -0400 Received: from foss.arm.com ([217.140.101.70]:48506 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730376AbfDBKnF (ORCPT ); Tue, 2 Apr 2019 06:43:05 -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 0E0D41688; Tue, 2 Apr 2019 03:43:05 -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 EB0323F59C; Tue, 2 Apr 2019 03:43:01 -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 14/16] sched/core: uclamp: Propagate system defaults to root group Date: Tue, 2 Apr 2019 11:41:50 +0100 Message-Id: <20190402104153.25404-15-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 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 e09cf8881567..de8391bafe11 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -980,6 +980,13 @@ static inline void uclamp_rq_dec(struct rq *rq, struct task_struct *p) uclamp_rq_dec_id(p, rq, 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) @@ -1017,6 +1024,9 @@ int sysctl_sched_uclamp_handler(struct ctl_table *table, int write, uclamp_bucket_id(sysctl_sched_uclamp_util_max); } + 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.20.1