linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Michal Koutný" <mkoutny@suse.com>
To: Patrick Bellasi <patrick.bellasi@arm.com>
Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>, Tejun Heo <tj@kernel.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>,
	Alessio Balsini <balsini@android.com>
Subject: Re: [PATCH v11 4/5] sched/core: uclamp: Use TG's clamps to restrict TASK's clamps
Date: Mon, 15 Jul 2019 18:42:49 +0200	[thread overview]
Message-ID: <20190715164248.GA21982@blackbody.suse.cz> (raw)
In-Reply-To: <20190708084357.12944-5-patrick.bellasi@arm.com>

On Mon, Jul 08, 2019 at 09:43:56AM +0100, Patrick Bellasi <patrick.bellasi@arm.com> wrote:
> This mimics what already happens for a task's CPU affinity mask when the
> task is also in a cpuset, i.e. cgroup attributes are always used to
> restrict per-task attributes.
If I am not mistaken when set_schedaffinity(2) call is made that results
in an empty cpuset, the call fails with EINVAL [1].

If I track the code correctly, the values passed to sched_setattr(2) are
checked against the trivial validity (umin <= umax) and later on, they
are adjusted to match the effective clamping of the containing
task_group. Is that correct?

If the user attempted to sched_setattr [a, b], and the effective uclamp
was [c, d] such that [a, b] ∩ [c, d] = ∅, the set uclamp will be
silently moved out of their intended range. Wouldn't it be better to
return with EINVAL too when the intersection is empty (since the user
supplied range won't be attained)?

Michal

[1] http://www.linux-arm.org/git?p=linux-pb.git;a=blob;f=kernel/sched/core.c;h=ddc5fcd4b9cfaa95496b24d8599c03bc140e768e;hb=2c15043a2a2b5d86eb409556cbe1e36d4fd275b5#l1660


  reply	other threads:[~2019-07-15 16:42 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-08  8:43 [PATCH v11 0/5] Add utilization clamping support (CGroups API) Patrick Bellasi
2019-07-08  8:43 ` [PATCH v11 1/5] sched/core: uclamp: Extend CPU's cgroup controller Patrick Bellasi
2019-07-08 11:08   ` Quentin Perret
2019-07-15 13:38     ` Patrick Bellasi
2019-07-18 14:52   ` Tejun Heo
2019-07-18 15:26     ` Patrick Bellasi
2019-07-08  8:43 ` [PATCH v11 2/5] sched/core: uclamp: Propagate parent clamps Patrick Bellasi
2019-07-15 16:42   ` Michal Koutný
2019-07-16 14:07     ` Patrick Bellasi
2019-07-16 15:29       ` Michal Koutný
2019-07-16 17:55         ` Patrick Bellasi
2019-07-08  8:43 ` [PATCH v11 3/5] sched/core: uclamp: Propagate system defaults to root group Patrick Bellasi
2019-07-15 16:42   ` Michal Koutný
2019-07-16 14:34     ` Patrick Bellasi
2019-07-16 15:36       ` Michal Koutný
2019-07-16 18:00         ` Patrick Bellasi
2019-07-16 15:46       ` Joel Fernandes
2019-07-08  8:43 ` [PATCH v11 4/5] sched/core: uclamp: Use TG's clamps to restrict TASK's clamps Patrick Bellasi
2019-07-15 16:42   ` Michal Koutný [this message]
2019-07-16 14:34     ` Patrick Bellasi
2019-07-16 15:58       ` Michal Koutný
2019-07-08  8:43 ` [PATCH v11 5/5] sched/core: uclamp: Update CPU's refcount on TG's clamp changes Patrick Bellasi
2019-07-15 16:51 ` [PATCH v11 0/5] Add utilization clamping support (CGroups API) Michal Koutný
2019-07-16 14:03   ` 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=20190715164248.GA21982@blackbody.suse.cz \
    --to=mkoutny@suse.com \
    --cc=balsini@android.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=joelaf@google.com \
    --cc=juri.lelli@redhat.com \
    --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=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).