linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Waiman Long <longman@redhat.com>
Cc: Li Zefan <lizefan@huawei.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	cgroups@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-doc@vger.kernel.org, kernel-team@fb.com, pjt@google.com,
	luto@amacapital.net, Mike Galbraith <efault@gmx.de>,
	torvalds@linux-foundation.org, Roman Gushchin <guro@fb.com>,
	Juri Lelli <juri.lelli@redhat.com>
Subject: Re: [PATCH v7 4/5] cpuset: Restrict load balancing off cpus to subset of cpus.isolated
Date: Tue, 1 May 2018 12:51:48 -0700	[thread overview]
Message-ID: <20180501195148.GC2368884@devbig577.frc2.facebook.com> (raw)
In-Reply-To: <1524145624-23655-5-git-send-email-longman@redhat.com>

Hello, Waiman.

Sorry about the delay.

On Thu, Apr 19, 2018 at 09:47:03AM -0400, Waiman Long wrote:
> With the addition of "cpuset.cpus.isolated", it makes sense to add the
> restriction that load balancing can only be turned off if the CPUs in
> the isolated cpuset are subset of "cpuset.cpus.isolated".
> 
> Signed-off-by: Waiman Long <longman@redhat.com>
> ---
>  Documentation/cgroup-v2.txt |  7 ++++---
>  kernel/cgroup/cpuset.c      | 29 ++++++++++++++++++++++++++---
>  2 files changed, 30 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/cgroup-v2.txt b/Documentation/cgroup-v2.txt
> index 8d89dc2..c4227ee 100644
> --- a/Documentation/cgroup-v2.txt
> +++ b/Documentation/cgroup-v2.txt
> @@ -1554,9 +1554,10 @@ Cpuset Interface Files
>  	and will not be moved to other CPUs.
>  
>  	This flag is hierarchical and is inherited by child cpusets. It
> -	can be turned off only when the CPUs in this cpuset aren't
> -	listed in the cpuset.cpus of other sibling cgroups, and all
> -	the child cpusets, if present, have this flag turned off.
> +	can be explicitly turned off only when it is a direct child of
> +	the root cgroup and the CPUs in this cpuset are subset of the
> +	root's "cpuset.cpus.isolated".	Moreover, the CPUs cannot be
> +	listed in the "cpuset.cpus" of other sibling cgroups.

It is a little bit convoluted that the isolation requires coordination
among root's isolated file and the first-level children's cpus file
and the flag.  Maybe I'm missing something but can't we do something
like the following?

* Add isolated flag file, which can only be modified on empty (in
  terms of cpus) first level children.

* Once isolated flag is set, CPUs can only be added to the cpus file
  iff they aren't being used by anyone else and automatically become
  isolated.

The first level cpus file is owned by the root cgroup anyway, so
there's no danger regarding delegation or whatever and the interface
would be a lot simpler.

Thanks.

-- 
tejun

  reply	other threads:[~2018-05-01 19:51 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-19 13:46 [PATCH v7 0/5] cpuset: Enable cpuset controller in default hierarchy Waiman Long
2018-04-19 13:47 ` [PATCH v7 1/5] " Waiman Long
2018-04-19 13:47 ` [PATCH v7 2/5] cpuset: Add cpuset.sched_load_balance to v2 Waiman Long
2018-05-02 10:24   ` Peter Zijlstra
2018-05-02 13:29     ` Waiman Long
2018-05-02 13:42       ` Peter Zijlstra
2018-05-02 13:47         ` Waiman Long
2018-05-02 14:02           ` Peter Zijlstra
2018-05-02 14:35             ` Mike Galbraith
2018-04-19 13:47 ` [PATCH v7 3/5] cpuset: Add a root-only cpus.isolated v2 control file Waiman Long
2018-04-23 15:56   ` Juri Lelli
2018-05-02 14:08   ` Peter Zijlstra
2018-05-08  0:30     ` Waiman Long
2018-04-19 13:47 ` [PATCH v7 4/5] cpuset: Restrict load balancing off cpus to subset of cpus.isolated Waiman Long
2018-05-01 19:51   ` Tejun Heo [this message]
2018-05-01 20:33     ` Waiman Long
2018-05-01 20:58       ` Tejun Heo
2018-05-01 21:31         ` Waiman Long
2018-04-19 13:47 ` [PATCH v7 5/5] cpuset: Make generate_sched_domains() recognize isolated_cpus Waiman Long
2018-04-20  8:23 ` [PATCH v7 0/5] cpuset: Enable cpuset controller in default hierarchy Mike Galbraith
2018-04-23 16:32   ` Waiman Long
2018-04-23 13:07 ` Juri Lelli
2018-04-23 13:57   ` Juri Lelli
2018-04-23 14:10     ` Waiman Long

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=20180501195148.GC2368884@devbig577.frc2.facebook.com \
    --to=tj@kernel.org \
    --cc=cgroups@vger.kernel.org \
    --cc=efault@gmx.de \
    --cc=guro@fb.com \
    --cc=hannes@cmpxchg.org \
    --cc=juri.lelli@redhat.com \
    --cc=kernel-team@fb.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizefan@huawei.com \
    --cc=longman@redhat.com \
    --cc=luto@amacapital.net \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=pjt@google.com \
    --cc=torvalds@linux-foundation.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).