linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick Bellasi <patrick.bellasi@arm.com>
To: "Michal Koutný" <mkoutny@suse.com>
Cc: cgroups@vger.kernel.org, linux-api@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
	Alessio Balsini <balsini@android.com>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Morten Rasmussen <morten.rasmussen@arm.com>,
	Quentin Perret <quentin.perret@arm.com>,
	Joel Fernandes <joelaf@google.com>, Paul Turner <pjt@google.com>,
	Steve Muckle <smuckle@google.com>,
	Suren Baghdasaryan <surenb@google.com>,
	Todd Kjos <tkjos@google.com>,
	Peter Zijlstra <peterz@infradead.org>,
	"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
	Tejun Heo <tj@kernel.org>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	Juri Lelli <juri.lelli@redhat.com>,
	Ingo Molnar <mingo@redhat.com>
Subject: Re: [PATCH v12 3/6] sched/core: uclamp: Propagate system defaults to root group
Date: Thu, 1 Aug 2019 12:10:54 +0100	[thread overview]
Message-ID: <20190801111054.6izrad6eysfnw5ju@e110439-lin> (raw)
In-Reply-To: <20190725114126.GA4130@blackbody.suse.cz>

On 25-Jul 13:41, Michal Koutný wrote:
> On Thu, Jul 18, 2019 at 07:17:45PM +0100, Patrick Bellasi <patrick.bellasi@arm.com> wrote:
> > The clamp values are not tunable at the level of the root task group.
> > That's for two main reasons:
> > 
> >  - the root group represents "system resources" which are always
> >    entirely available from the cgroup standpoint.
> > 
> >  - when tuning/restricting "system resources" makes sense, tuning must
> >    be done using a system wide API which should also be available when
> >    control groups are not.
> > 
> > When a system wide restriction is available, cgroups should be aware of
> > its value in order to know exactly how much "system resources" are
> > available for the subgroups.
> IIUC, the global default would apply in uclamp_eff_get(), so this
> propagation isn't strictly necessary in order to apply to tasks (that's
> how it works under !CONFIG_UCLAMP_TASK_GROUP).

That's right.

> The reason is that effective value (which isn't exposed currently) in a
> group takes into account this global restriction, right?

Yep, well admittedly in this area things changed in a slightly confusing way.

Up to v10:
 - effective values was exposed to userspace
 - system defaults was enforced only at enqueue time

Now instead:
 - effective values are not exposed anymore (because of Tejun request)
 - system defaults are applied to the root group and propagated down
   the hierarchy to all effective values

Both solutions are functionally correct but, in the first case, the
cgroup's effective values was not really reflecting what a task will
get while, in the current solution, we force update all effective
values while not exposing them anymore.

However, I think this solution is better in keeping information more
consistent and should create less confusion if in the future we decide
to expose effective values to user-space.

Thought?

> > @@ -1043,12 +1063,17 @@ int sysctl_sched_uclamp_handler(struct ctl_table *table, int write,
> > [...]
> > +	if (update_root_tg)
> > +		uclamp_update_root_tg();
> > +
> >  	/*
> >  	 * Updating all the RUNNABLE task is expensive, keep it simple and do
> >  	 * just a lazy update at each next enqueue time.
> Since uclamp_update_root_tg() traverses down to
> uclamp_update_active_tasks() is this comment half true now?

Right, this comment is now wrong. We update all RUNNABLE tasks on
system default changes. However, despite the above command it's
difficult to say how much expensive that operation can be.

It really depends on how many RUNNABLE tasks we have, the number of
CPUs and also how many tasks are not already clamped by a more
restrictive "effective" value. Thus, for the time being, we can
consider speculation the above statement and add in a simple change if
in the future that should be reported as a real issue to justify a
lazy update.

The upside is that with the current implementation we have a more
strict control on task. Even long running tasks can be clamped on
sysadmin demand without waiting for them to sleep.

Does that makes sense?

If it does, I'll drop the above comment in v13.

Cheers Patrick

-- 
#include <best/regards.h>

Patrick Bellasi

  reply	other threads:[~2019-08-01 11:11 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-18 18:17 [PATCH v12 0/6] Add utilization clamping support (CGroups API) Patrick Bellasi
2019-07-18 18:17 ` [PATCH v12 1/6] sched/core: uclamp: Extend CPU's cgroup controller Patrick Bellasi
2019-07-25 11:41   ` Michal Koutný
2019-08-01 10:40     ` Patrick Bellasi
2019-07-18 18:17 ` [PATCH v12 2/6] sched/core: uclamp: Propagate parent clamps Patrick Bellasi
2019-07-18 18:17 ` [PATCH v12 3/6] sched/core: uclamp: Propagate system defaults to root group Patrick Bellasi
2019-07-25 11:41   ` Michal Koutný
2019-08-01 11:10     ` Patrick Bellasi [this message]
2019-07-18 18:17 ` [PATCH v12 4/6] sched/core: uclamp: Use TG's clamps to restrict TASK's clamps Patrick Bellasi
2019-07-18 18:17 ` [PATCH v12 5/6] sched/core: uclamp: Update CPU's refcount on TG's clamp changes Patrick Bellasi
2019-07-18 18:17 ` [PATCH v12 6/6] sched/core: uclamp: always use enum uclamp_id for clamp_id values Patrick Bellasi
2019-07-29 20:06 ` [PATCH v12 0/6] Add utilization clamping support (CGroups API) Tejun Heo
2019-08-01 11:25   ` 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=20190801111054.6izrad6eysfnw5ju@e110439-lin \
    --to=patrick.bellasi@arm.com \
    --cc=balsini@android.com \
    --cc=cgroups@vger.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=mkoutny@suse.com \
    --cc=morten.rasmussen@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=tj@kernel.org \
    --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).