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: <linux-kernel-owner@vger.kernel.org>
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 <rfc822;zcyberian@gmail.com> + 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 <rfc822;linux-kernel@vger.kernel.org>);
        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 <patrick.bellasi@arm.com>,
        linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org
Cc:     Ingo Molnar <mingo@redhat.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Tejun Heo <tj@kernel.org>,
        "Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
        Viresh Kumar <viresh.kumar@linaro.org>,
        Vincent Guittot <vincent.guittot@linaro.org>,
        Paul Turner <pjt@google.com>,
        Morten Rasmussen <morten.rasmussen@arm.com>,
        Juri Lelli <juri.lelli@redhat.com>,
        Todd Kjos <tkjos@google.com>,
        Joel Fernandes <joelaf@google.com>,
        Steve Muckle <smuckle@google.com>,
        Suren Baghdasaryan <surenb@google.com>
References: <20180806163946.28380-1-patrick.bellasi@arm.com>
 <20180806163946.28380-10-patrick.bellasi@arm.com>
From:   Dietmar Eggemann <dietmar.eggemann@arm.com>
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: <linux-kernel.vger.kernel.org>
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}?

[...]