[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4b7znoqq6sdtutcn3jafyrucpqe5jylryvoeooz5ah54vbei4f@wxhsd7gkj3tp>
Date: Fri, 14 Nov 2025 17:15:05 +0100
From: Michal Koutný <mkoutny@...e.com>
To: Sun Shaojie <sunshaojie@...inos.cn>
Cc: llong@...hat.com, chenridong@...weicloud.com, cgroups@...r.kernel.org,
hannes@...xchg.org, linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
shuah@...nel.org, tj@...nel.org
Subject: Re: [PATCH v2] cpuset: relax the overlap check for cgroup-v2
On Fri, Nov 14, 2025 at 02:24:48PM +0800, Sun Shaojie <sunshaojie@...inos.cn> wrote:
> The desired outcome is that after step #5, although B1 writes "0-3" to
> cpuset.cpus, A1 can still remain as "root", and B1 ends up with effective
> CPUs of 2-3. In summary, We want to avoid A1's invalidation when B1
> changes its cpuset.cpus. Because cgroup v2 allows the effective CPU mask
> of a cpuset to differ from its requested mask.
So the new list of reasons why configured cpuset's cpus change are:
- hotplug,
- ancestor's config change,
- stealing by a sibling (new).
IIUC, the patch proposes this behavior:
echo root >A1.cpuset.partition
echo 0-1 >A1.cpuset.cpus
echo root >B1.cpuset.partition
echo 1-2 >B1.cpuset.cpus # invalidates A1
echo 0-1 >A1.cpuset.cpus # invalidates B1
ping-pong over CPU 1 ad libitum
I think the right (tm) behavior would be not to depend on the order in
which config is applied to siblings, i.e.
echo root >A1.cpuset.partition
echo 0-1 >A1.cpuset.cpus
echo root >B1.cpuset.partition
echo 1-2 >B1.cpuset.cpus # invalidates both A1 and B1
echo 0-1 >A1.cpuset.cpus # no change anymore
(I hope my example sheds some light on my understanding of the situation
and desired behavior.)
Thanks,
Michal
Download attachment "signature.asc" of type "application/pgp-signature" (266 bytes)
Powered by blists - more mailing lists