Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp789106imm; Fri, 17 Aug 2018 06:45:29 -0700 (PDT) X-Google-Smtp-Source: AA+uWPyR9BT1UEzSNGkJwY6elRadi+X8vYA0wbHclSn+oohNP6A4bwBBZIZOtpkSVkZ81vrR6W9J X-Received: by 2002:a63:4f63:: with SMTP id p35-v6mr32911622pgl.167.1534513529727; Fri, 17 Aug 2018 06:45:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534513529; cv=none; d=google.com; s=arc-20160816; b=H2MaeFwVMC3VREDNwchng/nng9Far+iA8BPSqGBliw3Hjqj8ev7uyW001B2lYlIaoS a5xia7Uzg46QtNj2d974azFfW9JotzeEtVubAQ/XgQsAjmFE90Ts7V1e0bB8lKnxjkpS i8E4cPK1UjLamFH3xduBDPwUNm3wJvQD/jhbJT30aKxUqnAIDaN7DZuymLllrRH9LX8W 6Qk5JAO+X9uG3KERZ08hWkmYqcZIc32oRdImIFH54E7VmT18FIX4qor1NHlNTLmoKwud 7H4M0l4X0synYBFW3VqrbVj/WwgD9GijiU8FW+pOTvC27rh3sNeKcCfBvIUudwBhdReF 8ywg== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=wuajZi/cAO3ir8l4ITNTWm3u4AUdzd54OJ/m+WSbYHc=; b=r/ibALxsAvxF/iBw5ZE7JgnGGEPHd5U7V9hdNQ6rbxeX1xc/H0Zps5Gm+FIeLEVE4C G3FSXpDy7RCd7DNaNcm5s8fXJac28gLaWKyEePIBK+g4Xuul/IAnyTDNN83Z/0Ipssa2 /AOZMiTr/E+g8mEraUM4UBssNlSM0Ufm/q1DVAMEZsqJcJE+ITGI/uuWbi4Gd3M7oUDH XQvTEknvWmVOEtY50fWaS/wPoBpDerlZSaZ//VJnY8boB+3Cl9QK7IEiOhghqF3F6yrP AlE8xT7h68vRAhLAy/np7HwVvLRANaAB4mH8uuVm2yka860OiD/YlDIEkyZ/7+qCiO4u +bEA== 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 l13-v6si2231382pgr.291.2018.08.17.06.45.14; Fri, 17 Aug 2018 06:45:29 -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 S1727440AbeHQQrh (ORCPT + 99 others); Fri, 17 Aug 2018 12:47:37 -0400 Received: from foss.arm.com ([217.140.101.70]:47478 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726355AbeHQQrh (ORCPT ); Fri, 17 Aug 2018 12:47:37 -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 3672F80D; Fri, 17 Aug 2018 06:44:11 -0700 (PDT) Received: from [0.0.0.0] (e107985-lin.emea.arm.com [10.4.12.239]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 62B353F5BC; Fri, 17 Aug 2018 06:44:02 -0700 (PDT) Subject: Re: [PATCH v3 09/14] sched/core: uclamp: propagate parent clamps To: Patrick Bellasi , 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 , Morten Rasmussen , Juri Lelli , Todd Kjos , Joel Fernandes , Steve Muckle , Suren Baghdasaryan References: <20180806163946.28380-1-patrick.bellasi@arm.com> <20180806163946.28380-10-patrick.bellasi@arm.com> From: Dietmar Eggemann Message-ID: <804c7937-2c47-0781-9c53-a8ef8eb04530@arm.com> Date: Fri, 17 Aug 2018 15:43:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20180806163946.28380-10-patrick.bellasi@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/06/2018 06:39 PM, Patrick Bellasi wrote: > In order to properly support hierarchical resources control, the cgroup > delegation model requires that attribute writes from a child group never > fail but still are (potentially) constrained based on parent's assigned > resources. This requires to properly propagate and aggregate parent > attributes down to its descendants. I don't understand the reason mentioned here: IMHO, a write to a child's (tg1/tg11) cpu.rt_runtime_us can fail if the value is restricted by the parents value: root@juno:/sys/fs/cgroup/cpu# cat cpu.rt_* 1000000 950000 root@juno:/sys/fs/cgroup/cpu# cat tg1/cpu.rt_* 1000000 0 root@juno:/sys/fs/cgroup/cpu# cat tg1/tg11/cpu.rt_* 1000000 0 root@juno:/sys/fs/cgroup/cpu# echo 950000 > tg1/tg11/cpu.rt_runtime_us -bash: echo: write error: Invalid argument root@juno:/sys/fs/cgroup/cpu# echo 950000 > tg1/cpu.rt_runtime_us root@juno:/sys/fs/cgroup/cpu# echo 950000 > tg1/tg11/cpu.rt_runtime_us root@juno:/sys/fs/cgroup/cpu# > Let's implement this mechanism by adding a new "effective" clamp value > for each task group. The effective clamp value is defined as the smaller > value between the clamp value of a group and the effective clamp value > of its parent. This represent also the clamp value which is actually > used to clamp tasks in each task group. > > Since it can be interesting for tasks in a cgroup to know exactly what > is the currently propagated/enforced configuration, the effective clamp > values are exposed to user-space by means of a new pair of read-only > attributes: cpu.util.{min,max}.effective. I assume here that the cpu.util.{min,max} of the child will not be used any more because the 'effective' counterparts are taken instead. I wonder if this propagation not been provided with only cpu.util.{min,max}? [...]