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: Peter Zijlstra <peterz@infradead.org>,
	Li Zefan <lizefan@huawei.com>,
	Johannes Weiner <hannes@cmpxchg.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>,
	Patrick Bellasi <patrick.bellasi@arm.com>
Subject: Re: [PATCH v11 7/9] cpuset: Expose cpus.effective and mems.effective on cgroup v2 root
Date: Thu, 19 Jul 2018 08:30:45 -0700	[thread overview]
Message-ID: <20180719153045.GT72677@devbig577.frc2.facebook.com> (raw)
In-Reply-To: <1107494a-9667-df58-dcac-9366e969dc3a@redhat.com>

Hello,

On Thu, Jul 19, 2018 at 10:04:54AM -0400, Waiman Long wrote:
> > Why would a container not be allowed to create partitions for its
> > various RT workloads?
> 
> As far as I understand, Tejun has some concern about the way that
> partitioning works is inconsistent with how other resources are being
> managed by cgroup v2 controllers. I adds an incremental patch to
> temporarily disable the creation of partition below the first level
> children to buy us time so that we can reach a compromise later on what
> to do. We can always add features, but taking away features after they
> are made available will be hard.
> 
> I am fine either way. It is up to you and Tejun to figure out what
> should be made available to the users.

So, the main thing is that putting a cpu into a partition locks away
the cpu from its ancestors.  That's a system level operation which
isn't delegatable.  If we want to allow partitioning in subtrees, the
parent still be able to take away partitioned cpus too even if that
means ignoring descendants' configurations, which btw is exactly what
cpuset does for non-partition configs.

I don't think this would be technically too challenging to implement,
but unless there are immediate use cases for it, we can start simpler
& restricted.

Thanks.

-- 
tejun

  reply	other threads:[~2018-07-19 15:30 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-24  7:30 [PATCH v11 0/9] cpuset: Enable cpuset controller in default hierarchy Waiman Long
2018-06-24  7:30 ` [PATCH v11 1/9] " Waiman Long
2018-06-24  7:30 ` [PATCH v11 2/9] cpuset: Add new v2 cpuset.sched.partition flag Waiman Long
2018-06-24  7:30 ` [PATCH v11 3/9] cpuset: Simulate auto-off of sched.partition at cgroup removal Waiman Long
2018-06-24  7:30 ` [PATCH v11 4/9] cpuset: Allow changes to cpus in a partition root Waiman Long
2018-06-24  7:30 ` [PATCH v11 5/9] cpuset: Make sure that partition flag work properly with CPU hotplug Waiman Long
2018-06-24  7:30 ` [PATCH v11 6/9] cpuset: Make generate_sched_domains() recognize reserved_cpus Waiman Long
2018-06-24  7:30 ` [PATCH v11 7/9] cpuset: Expose cpus.effective and mems.effective on cgroup v2 root Waiman Long
2018-07-02 16:53   ` Tejun Heo
2018-07-03  0:41     ` Waiman Long
2018-07-03 15:58       ` Tejun Heo
2018-07-06 20:32         ` Waiman Long
2018-07-10 15:23           ` Waiman Long
2018-07-18 15:21             ` Waiman Long
2018-07-18 15:31               ` Tejun Heo
2018-07-18 21:12                 ` Waiman Long
2018-07-19 13:52         ` Peter Zijlstra
2018-07-19 14:04           ` Waiman Long
2018-07-19 15:30             ` Tejun Heo [this message]
2018-07-19 15:52               ` Waiman Long
2018-07-19 16:52                 ` Tejun Heo
2018-07-19 17:22                   ` Waiman Long
2018-07-19 17:25                     ` Tejun Heo
2018-07-19 17:38                       ` Waiman Long
2018-07-20 11:32                     ` Peter Zijlstra
2018-07-20 11:31                   ` Peter Zijlstra
2018-07-20 11:45                     ` Tejun Heo
2018-07-20 12:04                       ` Tejun Heo
2018-07-20 15:44                       ` Peter Zijlstra
2018-07-20 15:56                         ` Tejun Heo
2018-07-20 16:19                           ` Waiman Long
2018-07-20 16:37                             ` Peter Zijlstra
2018-07-20 17:09                               ` Waiman Long
2018-07-20 17:41                                 ` Tejun Heo
2018-08-13 17:56                                   ` Waiman Long
2018-08-17 15:59                                     ` Tejun Heo
2018-08-18  1:03                                       ` Waiman Long
2018-07-27 21:21                                 ` Waiman Long
2018-07-20 16:25                           ` Peter Zijlstra
2018-07-20 15:57                         ` Waiman Long
2018-07-20 11:29               ` Peter Zijlstra
2018-06-24  7:30 ` [PATCH v11 8/9] cpuset: Don't rebuild sched domains if cpu changes in non-partition root Waiman Long
2018-06-24  7:30 ` [PATCH v11 9/9] cpuset: Allow reporting of sched domain generation info Waiman Long
2018-07-19 13:54   ` Peter Zijlstra
2018-07-19 13:56     ` 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=20180719153045.GT72677@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=patrick.bellasi@arm.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).