Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp855026imm; Fri, 17 Aug 2018 07:47:33 -0700 (PDT) X-Google-Smtp-Source: AA+uWPzya5pWbT4L9HhXBYtIKieCKCgFEDB0L3vttz2H6Jc55W69rjGtpTF3GSygtLksLzqA4bnw X-Received: by 2002:a17:902:aa83:: with SMTP id d3-v6mr33809530plr.242.1534517253228; Fri, 17 Aug 2018 07:47:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534517253; cv=none; d=google.com; s=arc-20160816; b=GAC7qBZZPfWtMF8mi7SmqY7ja6k2kGs6XahRGFRwo335nkcJkO3mcqRERYQWC7VERG Crv65DAwx6QhEVUhPoDX64dYexBHT1Ol3qiMUV2LImmAOUwL9oppMpMhj14L1DQ2Y1/r iwgxHvNLqrO9BEsY8PSOc8NerBe3ECba79N1t9u3aYnDUIAhTFa4bZwmrFm7ogl6ojNI mS5id1puAFnW16VTnDkeu6O4p24paH6sdL3nGYvFQvo+YtqBPaQ8bUR3RlhVjryEdu8e PA0kjLJPar/UDqu/UVamBfME5UqpQAoYedU9IOCeZa9+JUWju58iQEeoeOvaI21twUUi nStQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=HIQlokd4mN6IuyDY7gkHuG64pVPTrVKGhTWXkIvNqGI=; b=Qe7cXjoA4p/Mf5Gh/IB0jb5a9AHTUbVCggl0yC3+bGMAAFSoRbZ6vcDeKY6zlKXXHO 2OQ6Gp7/9SgGJ7lFUq49MWGd3HzWCY/oq+ExpnlcJmxKGdCnYn5WqfPIGV1od+0KvY7o TETkGBBiZfeSSsR3EsdC6J6HuseCnZ2045EQfQ6+TVJ2OhL3tVFOLJnDxLjsG8kfRFV8 cXohvdmm9Kd7hsGahi48MYXOQ/2ZV8ZRHKSzuX17AhuhCqW/jkFQoIZ5Is+hAOGHiaGn vbQRrUIAV6l5C3ujlE4FYRm2G5ypWFJITJa0sTiHZmPr6FvBJgUtnPEezrRdZYOGRpy5 HPZg== 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 a8-v6si2387879ple.189.2018.08.17.07.47.18; Fri, 17 Aug 2018 07:47:33 -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 S1727610AbeHQRtY (ORCPT + 99 others); Fri, 17 Aug 2018 13:49:24 -0400 Received: from foss.arm.com ([217.140.101.70]:48088 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726377AbeHQRtX (ORCPT ); Fri, 17 Aug 2018 13:49:23 -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 4DD7E80D; Fri, 17 Aug 2018 07:45:45 -0700 (PDT) Received: from e110439-lin (e110439-lin.Emea.Arm.com [10.4.12.126]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A234D3F5B3; Fri, 17 Aug 2018 07:45:42 -0700 (PDT) Date: Fri, 17 Aug 2018 15:45:40 +0100 From: Patrick Bellasi To: Dietmar Eggemann Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, 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 Subject: Re: [PATCH v3 09/14] sched/core: uclamp: propagate parent clamps Message-ID: <20180817144540.GL2960@e110439-lin> References: <20180806163946.28380-1-patrick.bellasi@arm.com> <20180806163946.28380-10-patrick.bellasi@arm.com> <804c7937-2c47-0781-9c53-a8ef8eb04530@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <804c7937-2c47-0781-9c53-a8ef8eb04530@arm.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 17-Aug 15:43, Dietmar Eggemann wrote: > 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: Well... that's my interpretation after this discussion: https://lore.kernel.org/lkml/20180410200514.GA793541@devbig577.frc2.facebook.com/ AFAIU, what has not to fail is a write to a parent, which wants to enforce more restrictive constraints to child groups. Thus, if we have for example: tg1: util_max=100% tg1/tg11: util_max=80% It should be possible without errors to set: tg1: util_max=50% and then enforce a 50% util_max to tg1/tg11 tasks too and eventually use "effective" attributes to expose the effective value used at each level of the hierarchy. > 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# This example is using the legacy hierarcy (cgroups v1). AFAIK the default hierarcy (cgroups v2) has a much more stricy set of requirements for the "delegation model". > >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. Yes, the "effective" attributes are the one used in kernel space for the actual clamping. However, the cpu.util.{min,max} of a child are still required as soon as the parent relax its constraints... when we use their value to set the "effective" value. > I wonder if this propagation not been provided with only cpu.util.{min,max}? In the example before, if we use the same variables we miss the opportunity to reset: tg1/tg11: util_max=80% as soon as tg1's util_max goes back to 100%. -- #include Patrick Bellasi