Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp1216815img; Tue, 19 Mar 2019 03:02:20 -0700 (PDT) X-Google-Smtp-Source: APXvYqz2Q8ceJYnw5ctpBh+06q//G/F269IrwgtbcTFEZfW8ifOmuh/51ENXErZtjAQAqgvT9yt6 X-Received: by 2002:a63:e101:: with SMTP id z1mr1441475pgh.190.1552989740240; Tue, 19 Mar 2019 03:02:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552989740; cv=none; d=google.com; s=arc-20160816; b=ZpdRCTQyk7/+PG0eGQ1AtOuYtTS7U/6VnqO2XPNvi0xvTfqUqg94vUAiusgcC31mML YfRDSEPyLOONuhsNQmS987RfvFLevzBp18wYSC8GUNb1ENpvarET+b+NrOpCQfgoJdng D4+u+AzbgtiykCJOU8u6r2oMYlVJfa4e73g+RrkVFUFKXJAuy1rC1f0n+esoCBrjOAM1 +KHqvINe7mBgZOawMehF7zRrfknq/eadeUXdNrrRyFnRsmqkx8y7KuYM5LQHU82CQO5M xGA356+lQK3FWMaxs/DB7I60JHBsUfWkcpAXPLckMUPQ0IK09FP/pzfPWiyQlrnynJkL SY4A== 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; bh=JUnKhSOQPHLYEto6BBfH5ekD6XFUO8mT9X2s9D5QK/c=; b=tD7qNFUBbmPbb/KG+OD/H4FE//iP9E5IgXnYNiGORiiaJG0CJ3wCR2uiq49fht7Fn5 rC9GLWI0z4bs4F3d4lKLq7K3sQx4eQw/4gX84smJLA2eS1QW+BcIl9+6zCLdqCQdOXmV jGDkU+Qr+z+p+zoD6gmA9HcdDDIlFvT2SuxN5n+DUP0fM8Cc6DotK0xzdQqwXQS0qyNE quRF1XpD0NFj4FbX2uo+RwBokQd6lfdAr8nSexL3ttsdHv/e6MlBD+7QrNnnCZs8qm2F gayxEDx0zpjOz3uP02YqzOH52//WiSS5IztsOChQ60PVqWAdcccWIWmbjvQgovh3u2jK soHw== 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 q29si4020455pfi.98.2019.03.19.03.02.04; Tue, 19 Mar 2019 03:02:20 -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 S1727389AbfCSKAp (ORCPT + 99 others); Tue, 19 Mar 2019 06:00:45 -0400 Received: from foss.arm.com ([217.140.101.70]:48428 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726712AbfCSKAp (ORCPT ); Tue, 19 Mar 2019 06:00:45 -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 5FE3A1650; Tue, 19 Mar 2019 03:00:44 -0700 (PDT) Received: from e110439-lin (e110439-lin.cambridge.arm.com [10.1.194.43]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6B71C3F575; Tue, 19 Mar 2019 03:00:41 -0700 (PDT) Date: Tue, 19 Mar 2019 10:00:35 +0000 From: Patrick Bellasi To: Tejun Heo Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-api@vger.kernel.org, Ingo Molnar , Peter Zijlstra , "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: Re: [PATCH v7 11/15] sched/core: uclamp: Extend CPU's cgroup controller Message-ID: <20190319100035.mzuuynaobp7hrbtf@e110439-lin> References: <20190208100554.32196-1-patrick.bellasi@arm.com> <20190208100554.32196-12-patrick.bellasi@arm.com> <20190214154817.GN50184@devbig004.ftw2.facebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190214154817.GN50184@devbig004.ftw2.facebook.com> User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 14-Feb 07:48, Tejun Heo wrote: > Hello, Hi Tejun, > On Fri, Feb 08, 2019 at 10:05:50AM +0000, Patrick Bellasi wrote: > > a) are available only for non-root nodes, both on default and legacy > > hierarchies, while system wide clamps are defined by a generic > > interface which does not depends on cgroups > > > > b) do not enforce any constraints and/or dependencies between the parent > > and its child nodes, thus relying: > > - on permission settings defined by the system management software, > > to define if subgroups can configure their clamp values > > - on the delegation model, to ensure that effective clamps are > > updated to consider both subgroup requests and parent group > > constraints > > I'm not sure about this hierarchical behavior. Yes, the above paragraph is misleading and it fails in properly document what the code really does. I'll update it on v8 to be more clear. > > > c) have higher priority than task-specific clamps, defined via > > sched_setattr(), thus allowing to control and restrict task requests > > and I have some other concerns about the interface, but let's discuss > them once the !cgroup portion is settled. Sure, looking forward to get some more feedbacks from you on that part. For the time being I'll keep adding the cgroups bits on top of the core ones just to follow the principle of "share early, share often" and to give interested people a more complete picture of our final goal. I'm sure Peter will let you know when it's worth for you to be more actively involved with the review ;) > Thanks. Cheers, Patrick -- #include Patrick Bellasi