From: Tejun Heo <tj@kernel.org>
To: Waiman Long <longman@redhat.com>
Cc: "Michal Koutný" <mkoutny@suse.com>,
"Zefan Li" <lizefan.x@bytedance.com>,
"Johannes Weiner" <hannes@cmpxchg.org>,
"Jonathan Corbet" <corbet@lwn.net>,
"Shuah Khan" <shuah@kernel.org>,
linux-kernel@vger.kernel.org, cgroups@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org,
"Juri Lelli" <juri.lelli@redhat.com>,
"Valentin Schneider" <vschneid@redhat.com>,
"Frederic Weisbecker" <frederic@kernel.org>,
"Mrunal Patel" <mpatel@redhat.com>,
"Ryan Phillips" <rphillips@redhat.com>,
"Brent Rowsell" <browsell@redhat.com>,
"Peter Hunt" <pehunt@redhat.com>, "Phil Auld" <pauld@redhat.com>
Subject: Re: [RFC PATCH 0/5] cgroup/cpuset: A new "isolcpus" paritition
Date: Tue, 6 Jun 2023 09:58:37 -1000 [thread overview]
Message-ID: <ZH-P7X_yjnVfhy7b@slm.duckdns.org> (raw)
In-Reply-To: <a2220c9f-7a8d-da82-ecc0-b39f3807408c@redhat.com>
Hello, Waiman.
On Mon, Jun 05, 2023 at 10:47:08PM -0400, Waiman Long wrote:
...
> I had a different idea on the semantics of the cpuset.cpus.exclusive at the
> beginning. My original thinking is that it was the actual exclusive CPUs
> that are allocated to the cgroup. Now if we treat this as a hint of what
> exclusive CPUs should be used and it becomes valid only if the cgroup can
I wouldn't call it a hint. It's still hard allocation of the CPUs to the
cgroups that own them. Setting up a partition requires exclusive CPUs and
thus would depend on exclusive allocations set up accordingly.
> become a valid partition. I can see it as a value that can be hierarchically
> set throughout the whole cpuset hierarchy.
>
> So a transition to a valid partition is possible iff
>
> 1) cpuset.cpus.exclusive is a subset of cpuset.cpus and is a subset of
> cpuset.cpus.exclusive of all its ancestors.
Yes.
> 2) If its parent is not a partition root, none of the CPUs in
> cpuset.cpus.exclusive are currently allocated to other partitions. This the
Not just that, the CPUs aren't available to cgroups which don't have them
set in the .exclusive file. IOW, if a CPU is in cpus.exclusive of some
cgroups, it shouldn't appear in cpus.effective of cgroups which don't have
the CPU in their cpus.exclusive.
So, .exclusive explicitly establishes exclusive ownership of CPUs and
partitions depend on that with an implicit "turn CPUs exclusive" behavior in
case the parent is a partition root for backward compatibility.
> same remote partition concept in my v2 patch. If its parent is a partition
> root, part of its exclusive CPUs will be distributed to this child partition
> like the current behavior of cpuset partition.
Yes, similar in a sense. Please do away with the "once .reserve is used, the
behavior is switched" part. Instead, it can be sth like "if the parent is a
partition root, cpuset implicitly tries to set all CPUs in its cpus file in
its cpus.exclusive file" so that user-visible behavior stays unchanged
depending on past history.
Thanks.
--
tejun
next prev parent reply other threads:[~2023-06-06 19:58 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-12 15:37 [RFC PATCH 0/5] cgroup/cpuset: A new "isolcpus" paritition Waiman Long
2023-04-12 19:28 ` Tejun Heo
[not found] ` <1ce6a073-e573-0c32-c3d8-f67f3d389a28@redhat.com>
2023-04-12 20:22 ` Tejun Heo
2023-04-12 20:33 ` Waiman Long
2023-04-13 0:03 ` Tejun Heo
2023-04-13 0:26 ` Waiman Long
2023-04-13 0:33 ` Tejun Heo
2023-04-13 0:55 ` Waiman Long
2023-04-13 1:17 ` Tejun Heo
2023-04-13 1:55 ` Waiman Long
2023-04-14 1:22 ` Waiman Long
2023-04-14 16:54 ` Tejun Heo
2023-04-14 17:29 ` Waiman Long
2023-04-14 17:34 ` Tejun Heo
2023-04-14 17:38 ` Waiman Long
2023-04-14 19:06 ` Waiman Long
2023-05-02 18:01 ` Michal Koutný
2023-05-02 21:26 ` Waiman Long
2023-05-02 22:27 ` Michal Koutný
2023-05-04 3:01 ` Waiman Long
2023-05-05 16:03 ` Tejun Heo
2023-05-05 16:25 ` Waiman Long
2023-05-08 1:03 ` Waiman Long
2023-05-22 19:49 ` Tejun Heo
2023-05-28 21:18 ` Waiman Long
2023-06-05 18:03 ` Tejun Heo
2023-06-05 20:00 ` Waiman Long
2023-06-05 20:27 ` Tejun Heo
2023-06-06 2:47 ` Waiman Long
2023-06-06 19:58 ` Tejun Heo [this message]
2023-06-06 20:11 ` Waiman Long
2023-06-06 20:13 ` Tejun Heo
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=ZH-P7X_yjnVfhy7b@slm.duckdns.org \
--to=tj@kernel.org \
--cc=browsell@redhat.com \
--cc=cgroups@vger.kernel.org \
--cc=corbet@lwn.net \
--cc=frederic@kernel.org \
--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=longman@redhat.com \
--cc=mkoutny@suse.com \
--cc=mpatel@redhat.com \
--cc=pauld@redhat.com \
--cc=pehunt@redhat.com \
--cc=rphillips@redhat.com \
--cc=shuah@kernel.org \
--cc=vschneid@redhat.com \
/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