linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Patrick Bellasi <patrick.bellasi@arm.com>
Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
	linux-api@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	Paul Turner <pjt@google.com>,
	Quentin Perret <quentin.perret@arm.com>,
	Dietmar Eggemann <dietmar.eggemann@arm.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>
Subject: Re: [PATCH v9 12/16] sched/core: uclamp: Extend CPU's cgroup controller
Date: Wed, 5 Jun 2019 07:03:24 -0700	[thread overview]
Message-ID: <20190605140324.GL374014@devbig004.ftw2.facebook.com> (raw)
In-Reply-To: <20190603122725.GB19426@darkstar>

Hello,

On Mon, Jun 03, 2019 at 01:27:25PM +0100, Patrick Bellasi wrote:
> All the above, to me it means that:
>  - cgroups are always capped by system clamps
>  - cgroups can further restrict system clamps
> 
> Does that match with your view?

Yeah, as long as what's defined at system level clamps everything in
the system whether they're in cgroups or not, it's all good.

> > * Limits (high / max) default to max.  Protections (low / min) 0.  A
> >   new cgroup by default doesn't constrain itself further and doesn't
> >   have any protection.
> 
> Example 2
> ---------
> 
> Let say we have:
> 
>   /tg1:
>         util_min=200 (as a protection)
>         util_max=800 (as a limit)
> 
> the moment we create a subgroup /tg1/tg11, in v9 it is initialized
> with the same limits _and protections_ of its father:
> 
>   /tg1/tg11:
>         util_min=200 (protection inherited from /tg1)
>         util_max=800 (limit inherited from /tg1)
> 
> Do you mean that we should have instead:
> 
>   /tg1/tg11:
>         util_min=0   (no protection by default at creation time)
>         util_max=800 (limit inherited from /tg1)
> 
> 
> i.e. we need to reset the protection of a newly created subgroup?

The default value for limits should be max, protections 0.  Don't
inherit config values from the parent.  That gets confusing super fast
because when the parent config is set and each child is created plays
into the overall configuration.  Hierarchical confinements should
always be enforced and a new cgroup should always start afresh in
terms of its own configuration.

> > * A limit defines the upper ceiling for the subtree.  If an ancestor
> >   has a limit of X, none of its descendants can have more than X.
> 
> That's correct, however we distinguish between "requested" and
> "effective" values.

Sure, all property propagating controllers should.

> > Note that there's no way for an ancestor to enforce protection its
> > descendants.  It can only allow them to claim some.  This is
> > intentional as the other end of the spectrum is either descendants
> > losing the ability to further distribute protections as they see fit.
> 
> Ok, that means I need to update in v10 the initialization of subgroups
> min clamps to be none by default as discussed in the above Example 2,
> right?

Yeah and max to max.

Thanks.

-- 
tejun

  reply	other threads:[~2019-06-05 14:03 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-15  9:44 [PATCH v9 00/16] Add utilization clamping support Patrick Bellasi
2019-05-15  9:44 ` [PATCH v9 01/16] sched/core: uclamp: Add CPU's clamp buckets refcounting Patrick Bellasi
2019-05-15  9:44 ` [PATCH v9 02/16] sched/core: uclamp: Add bucket local max tracking Patrick Bellasi
2019-05-15  9:44 ` [PATCH v9 03/16] sched/core: uclamp: Enforce last task's UCLAMP_MAX Patrick Bellasi
2019-05-15  9:44 ` [PATCH v9 04/16] sched/core: uclamp: Add system default clamps Patrick Bellasi
2019-05-15  9:44 ` [PATCH v9 05/16] sched/core: Allow sched_setattr() to use the current policy Patrick Bellasi
2019-05-15  9:44 ` [PATCH v9 06/16] sched/core: uclamp: Extend sched_setattr() to support utilization clamping Patrick Bellasi
2019-05-15  9:44 ` [PATCH v9 07/16] sched/core: uclamp: Reset uclamp values on RESET_ON_FORK Patrick Bellasi
2019-05-15  9:44 ` [PATCH v9 08/16] sched/core: uclamp: Set default clamps for RT tasks Patrick Bellasi
2019-05-15  9:44 ` [PATCH v9 09/16] sched/cpufreq: uclamp: Add clamps for FAIR and " Patrick Bellasi
2019-05-15  9:44 ` [PATCH v9 10/16] sched/core: uclamp: Add uclamp_util_with() Patrick Bellasi
2019-05-15  9:44 ` [PATCH v9 11/16] sched/fair: uclamp: Add uclamp support to energy_compute() Patrick Bellasi
2019-05-15  9:44 ` [PATCH v9 12/16] sched/core: uclamp: Extend CPU's cgroup controller Patrick Bellasi
2019-05-31 15:35   ` Tejun Heo
2019-06-03 12:24     ` Patrick Bellasi
2019-06-03 12:27     ` Patrick Bellasi
2019-06-05 14:03       ` Tejun Heo [this message]
2019-06-05 14:39         ` Patrick Bellasi
2019-06-05 14:44           ` Tejun Heo
2019-06-05 15:37             ` Patrick Bellasi
2019-06-05 15:39               ` Tejun Heo
2019-06-03 12:29     ` Patrick Bellasi
2019-06-05 14:09       ` Tejun Heo
2019-06-05 15:06         ` Patrick Bellasi
2019-06-05 15:27           ` Tejun Heo
2019-05-15  9:44 ` [PATCH v9 13/16] sched/core: uclamp: Propagate parent clamps Patrick Bellasi
2019-05-15  9:44 ` [PATCH v9 14/16] sched/core: uclamp: Propagate system defaults to root group Patrick Bellasi
2019-05-15  9:44 ` [PATCH v9 15/16] sched/core: uclamp: Use TG's clamps to restrict TASK's clamps Patrick Bellasi
2019-05-15  9:44 ` [PATCH v9 16/16] sched/core: uclamp: Update CPU's refcount on TG's clamp changes Patrick Bellasi
2019-05-30 10:15 ` [PATCH v9 00/16] Add utilization clamping support Patrick Bellasi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190605140324.GL374014@devbig004.ftw2.facebook.com \
    --to=tj@kernel.org \
    --cc=dietmar.eggemann@arm.com \
    --cc=joelaf@google.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=morten.rasmussen@arm.com \
    --cc=patrick.bellasi@arm.com \
    --cc=peterz@infradead.org \
    --cc=pjt@google.com \
    --cc=quentin.perret@arm.com \
    --cc=rafael.j.wysocki@intel.com \
    --cc=smuckle@google.com \
    --cc=surenb@google.com \
    --cc=tkjos@google.com \
    --cc=vincent.guittot@linaro.org \
    --cc=viresh.kumar@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).