From: Tejun Heo <tj@kernel.org>
To: Waiman Long <llong@redhat.com>
Cc: "Zefan Li" <lizefan.x@bytedance.com>,
"Johannes Weiner" <hannes@cmpxchg.org>,
"Jonathan Corbet" <corbet@lwn.net>,
"Shuah Khan" <shuah@kernel.org>,
cgroups@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org,
"Andrew Morton" <akpm@linux-foundation.org>,
"Roman Gushchin" <guro@fb.com>, "Phil Auld" <pauld@redhat.com>,
"Peter Zijlstra" <peterz@infradead.org>,
"Juri Lelli" <juri.lelli@redhat.com>,
"Frederic Weisbecker" <frederic@kernel.org>,
"Marcelo Tosatti" <mtosatti@redhat.com>,
"Michal Koutný" <mkoutny@suse.com>
Subject: Re: [PATCH v7 5/6] cgroup/cpuset: Update description of cpuset.cpus.partition in cgroup-v2.rst
Date: Fri, 27 Aug 2021 13:35:39 -1000 [thread overview]
Message-ID: <YSl2yxEvnDrPxzUV@slm.duckdns.org> (raw)
In-Reply-To: <392c3724-f583-c7fc-cfa1-a3f1665114c9@redhat.com>
Hello,
On Fri, Aug 27, 2021 at 06:50:10PM -0400, Waiman Long wrote:
> The cpu exclusivity rule is due to the setting of CPU_EXCLUSIVE bit. This is
> a pre-existing condition unless you want to change how the
> cpuset.cpu_exclusive works.
>
> So the new rules will be:
>
> 1) The "cpuset.cpus" is not empty and the list of CPUs are exclusive.
Empty cpu list can be considered an exclusive one.
> 2) The parent cgroup is a partition root (can be an invalid one).
Does this mean a partition parent can't stop being a partition if one or
more of its children become partitions? If so, it violates the rule that a
descendant shouldn't be able to restrict what its ancestors can do.
> 3) The "cpuset.cpus" is a subset of the parent's cpuset.cpus.allowed.
Why not just go by effective? This would mean that a parent can't withdraw
CPUs from its allowed set once descendants are configured. Restrictions like
this are fine when the entire hierarchy is configured by a single entity but
become awkward when configurations are multi-tiered, automated and dynamic.
> 4) No child cgroup with cpuset enabled.
idk, maybe? I'm having a hard time seeing the point in adding these
restrictions when the state transitions are asynchronous anyway. Would it
help if we try to separate what's absoluately and technically necessary and
what seems reasonable or high bar and try to justify why each of the latter
should be added?
Thanks.
--
tejun
next prev parent reply other threads:[~2021-08-27 23:35 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-25 21:37 [PATCH v7 0/6] cgroup/cpuset: Add new cpuset partition type & empty effecitve cpus Waiman Long
2021-08-25 21:37 ` [PATCH v7 1/6] cgroup/cpuset: Properly transition to invalid partition Waiman Long
2021-08-25 21:37 ` [PATCH v7 2/6] cgroup/cpuset: Show invalid partition reason string Waiman Long
2021-08-25 21:37 ` [PATCH v7 3/6] cgroup/cpuset: Add a new isolated cpus.partition type Waiman Long
2021-08-25 21:37 ` [PATCH v7 4/6] cgroup/cpuset: Allow non-top parent partition to distribute out all CPUs Waiman Long
2021-08-25 21:37 ` [PATCH v7 5/6] cgroup/cpuset: Update description of cpuset.cpus.partition in cgroup-v2.rst Waiman Long
2021-08-26 17:35 ` Tejun Heo
2021-08-27 3:01 ` Waiman Long
2021-08-27 4:00 ` Tejun Heo
2021-08-27 21:19 ` Waiman Long
2021-08-27 21:27 ` Tejun Heo
2021-08-27 22:50 ` Waiman Long
2021-08-27 23:35 ` Tejun Heo [this message]
2021-08-28 1:14 ` Waiman Long
[not found] ` <3533e4f9-169c-d13c-9c4e-d9ec6bdc78f0@redhat.com>
2021-10-12 14:39 ` Michal Koutný
2021-10-13 21:45 ` Waiman Long
2021-10-13 22:11 ` Waiman Long
2021-08-30 17:59 ` Michal Koutný
2021-08-25 21:37 ` [PATCH v7 6/6] kselftest/cgroup: Add cpuset v2 partition root state test 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=YSl2yxEvnDrPxzUV@slm.duckdns.org \
--to=tj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=corbet@lwn.net \
--cc=frederic@kernel.org \
--cc=guro@fb.com \
--cc=hannes@cmpxchg.org \
--cc=juri.lelli@redhat.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=lizefan.x@bytedance.com \
--cc=llong@redhat.com \
--cc=mkoutny@suse.com \
--cc=mtosatti@redhat.com \
--cc=pauld@redhat.com \
--cc=peterz@infradead.org \
--cc=shuah@kernel.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).