[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b6d9088e-bd35-47c5-a891-4ad3705fd1a6@huaweicloud.com>
Date: Sat, 15 Nov 2025 17:51:23 +0800
From: Chen Ridong <chenridong@...weicloud.com>
To: Michal Koutný <mkoutny@...e.com>,
Sun Shaojie <sunshaojie@...inos.cn>
Cc: llong@...hat.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 2025/11/15 10:01, Chen Ridong wrote:
>
>
> On 2025/11/15 0:15, Michal Koutný wrote:
>> 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.)
>
> Before applying the patch, the behavior I got:
>
> # cd /sys/fs/cgroup/
> # mkdir A1
> # mkdir B1
> # echo root > A1/cpuset.cpus.partition
> # echo 0-1 > A1/cpuset.cpus
> # cat A1/cpuset.cpus.partition
> root
> # echo root > B1/cpuset.cpus.partition
> # echo 1-2 > B1/cpuset.cpus # A1 is exclusive, invalidate both A1 and B1
> # cat A1/cpuset.cpus.partition
> root invalid
> # cat B1/cpuset.cpus.partition
> root invalid (cpuset.cpus and cpuset.cpus.exclusive are empty)
> # echo root > B1/cpuset.cpus.partition
> # cat B1/cpuset.cpus.partition
> root invalid (Cpu list in cpuset.cpus not exclusive)
> # echo root > A1/cpuset.cpus.partition
> # cat A1/cpuset.cpus.partition
> root invalid (Cpu list in cpuset.cpus not exclusive)
> #
>
> After applying the patch, the behavior I got:
>
> # cd /sys/fs/cgroup/
> # mkdir A1
> # mkdir B1
> # echo root > A1/cpuset.cpus.partition
> # echo 0-1 > A1/cpuset.cpus
> # cat A1/cpuset.cpus.partition
> root
> # echo root > B1/cpuset.cpus.partition
> # echo 1-2 > B1/cpuset.cpus # A1 is exclusive, B1 is going to be exclusive
> # cat A1/cpuset.cpus.partition
> root
> # cat B1/cpuset.cpus.partition # A1 and B1 should be invalid.
> root
> # echo member > B1/cpuset.cpus.partition
> # echo root > B1/cpuset.cpus.partition
> # cat A1/cpuset.cpus.partition
> root
> # cat B1/cpuset.cpus.partition
> root invalid (Cpu list in cpuset.cpus not exclusive)
> # echo member > A1/cpuset.cpus.partition
> # echo root > B1/cpuset.cpus.partition
> # echo root > A1/cpuset.cpus.partition
> # cat A1/cpuset.cpus.partition
> root invalid (Cpu list in cpuset.cpus not exclusive)
> # cat B1/cpuset.cpus.partition
> root
>
> After applying the patch, The result is unexpected.
>
This may trigger another related corner case, I sent a patch to fix it:
https://lore.kernel.org/cgroups/20251115093140.1121329-1-chenridong@huaweicloud.com/T/#mfc4157e23d253b71ef9a2cfa5cb54bf41449840c
--
Best regards,
Ridong
Powered by blists - more mailing lists