Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp6556410ybi; Mon, 8 Jul 2019 05:00:57 -0700 (PDT) X-Google-Smtp-Source: APXvYqyZYaqyHVXG17DT7oGSil7XkOSvX6Ie3c2vIkexHap3sYinOcFVjnxBCSV9lYLe4OyY1Fy3 X-Received: by 2002:a17:90a:8c90:: with SMTP id b16mr24786933pjo.133.1562587257124; Mon, 08 Jul 2019 05:00:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562587257; cv=none; d=google.com; s=arc-20160816; b=vARdNhpE0YpnvMzp7DMQCKfrb/WPuUJiGYTS3J4WqzLHwNYh1VI5eMZX0kRv1DZLGv gGLQouX83speBJO2yX231FNAXg20ZkezQayHxYsmIRr8ujLvpCjOqQpuPUXrfHGBpJ1T 26PaaHPFbWa6KJQ0Kxn6de+zVs/RKY5MShVkkOg92vOL2PkdjCq53PwSsqUDGDsO7DF+ GNK9TwjdPqjmqjhsT55SSucLB2bEyG9vAh2ULJLvQDnVRGcB3jL4ykFSkLqjagARi8UL T2DKCzIDT9Dge943mlmfNLKsnagInzGGp/1ug8+YGpoLb4ZstCby3/l6vkZrR2KcE/GG B4hg== 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=SNzflbwizmgY9BfYEfm098TdJoIoGPzorr6vTdBXRXQ=; b=Ak7dRLgdzXgvEzgDhsFCLawjWImqjXTtK63Q+wwqBRsguVHUVzUFWl9lIX0IjmCK5e WxTqVScnJMFeT17FsUCIa+0SyEbrWq8i4BjSRhJu1SCuhfHKi0QeqejE3jneZWikYmVS XIkXom6m6rt8PQaqmwveaRhoWYqE/k9LF3dQ4Vdw4c1ki/yCRYbkoAiq0cuKY0RWLVnv TcT30ld6dMnjqubgVkUar4sR46WuR42Zlkvlm9DBabTXDbECWsWsoTUWsQQrlYED9tcN UwithX6VrquCIhjhUEbX43/dNeeNUQ++EjNecST2r5M1er7OxvU2lCtQwMODS7r6yuar MMsw== 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 s8si19257197pfh.276.2019.07.08.05.00.41; Mon, 08 Jul 2019 05:00:57 -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 S1729624AbfGHIoX (ORCPT + 99 others); Mon, 8 Jul 2019 04:44:23 -0400 Received: from foss.arm.com ([217.140.110.172]:41996 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729602AbfGHIoW (ORCPT ); Mon, 8 Jul 2019 04:44:22 -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 34FA1152B; Mon, 8 Jul 2019 01:44:21 -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 D5FB23F246; Mon, 8 Jul 2019 01:44:18 -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 v11 4/5] sched/core: uclamp: Use TG's clamps to restrict TASK's clamps Date: Mon, 8 Jul 2019 09:43:56 +0100 Message-Id: <20190708084357.12944-5-patrick.bellasi@arm.com> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190708084357.12944-1-patrick.bellasi@arm.com> References: <20190708084357.12944-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 When a task specific clamp value is configured via sched_setattr(2), this value is accounted in the corresponding clamp bucket every time the task is {en,de}qeued. However, when cgroups are also in use, the task specific clamp values could be restricted by the task_group (TG) clamp values. Update uclamp_cpu_inc() to aggregate task and TG clamp values. Every time a task is enqueued, it's accounted in the clamp bucket tracking the smaller clamp between the task specific value and its TG effective value. This allows to: 1. ensure cgroup clamps are always used to restrict task specific requests, i.e. boosted not more than its TG effective protection and capped at least as its TG effective limit. 2. implement a "nice-like" policy, where tasks are still allowed to request less than what enforced by their TG effective limits and protections This mimics what already happens for a task's CPU affinity mask when the task is also in a cpuset, i.e. cgroup attributes are always used to restrict per-task attributes. Do this by exploiting the concept of "effective" clamp, which is already used by a TG to track parent enforced restrictions. Apply task group clamp restrictions only to tasks belonging to a child group. While, for tasks in the root group or in an autogroup, only system defaults are enforced. Signed-off-by: Patrick Bellasi Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Tejun Heo --- kernel/sched/core.c | 28 +++++++++++++++++++++++++++- 1 file changed, 27 insertions(+), 1 deletion(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 276f9c2f6103..2591a70c85cf 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -873,16 +873,42 @@ unsigned int uclamp_rq_max_value(struct rq *rq, unsigned int clamp_id, return uclamp_idle_value(rq, clamp_id, clamp_value); } +static inline struct uclamp_se +uclamp_tg_restrict(struct task_struct *p, unsigned int clamp_id) +{ + struct uclamp_se uc_req = p->uclamp_req[clamp_id]; +#ifdef CONFIG_UCLAMP_TASK_GROUP + struct uclamp_se uc_max; + + /* + * Tasks in autogroups or root task group will be + * restricted by system defaults. + */ + if (task_group_is_autogroup(task_group(p))) + return uc_req; + if (task_group(p) == &root_task_group) + return uc_req; + + uc_max = task_group(p)->uclamp[clamp_id]; + if (uc_req.value > uc_max.value || !uc_req.user_defined) + return uc_max; +#endif + + return uc_req; +} + /* * The effective clamp bucket index of a task depends on, by increasing * priority: * - the task specific clamp value, when explicitly requested from userspace + * - the task group effective clamp value, for tasks not either in the root + * group or in an autogroup * - the system default clamp value, defined by the sysadmin */ static inline struct uclamp_se uclamp_eff_get(struct task_struct *p, unsigned int clamp_id) { - struct uclamp_se uc_req = p->uclamp_req[clamp_id]; + struct uclamp_se uc_req = uclamp_tg_restrict(p, clamp_id); struct uclamp_se uc_max = uclamp_default[clamp_id]; /* System default restrictions always apply */ -- 2.21.0