On 2026/1/5 5:48, Waiman Long wrote:
> On 1/4/26 2:09 AM, Chen Ridong wrote:
>>
>> On 2026/1/2 3:15, Waiman Long wrote:
>>> Commit fe8cd2736e75 ("cgroup/cpuset: Delay setting of CS_CPU_EXCLUSIVE
>>> until valid partition") introduced a new check to disallow the setting
>>> of a new cpuset.cpus.exclusive value that is a superset of a sibling's
>>> cpuset.cpus value so that there will at least be one CPU left in the
>>> sibling in case the cpuset becomes a valid partition root. This new
>>> check does have the side effect of failing a cpuset.cpus change that
>>> make it a subset of a sibling's cpuset.cpus.exclusive value.
>>>
>>> With v2, users are supposed to be allowed to set whatever value they
>>> want in cpuset.cpus without failure. To maintain this rule, the check
>>> is now restricted to only when cpuset.cpus.exclusive is being changed
>>> not when cpuset.cpus is changed.
>>>
>> Hi, Longman,
>>
>> You've emphasized that modifying cpuset.cpus should never fail. While I
>> haven't found this
>> explicitly documented. Should we add it?
>>
>> More importantly, does this mean the "never fail" rule has higher priority
>> than the exclusive CPU
>> constraints? This seems to be the underlying assumption in this patch.
>
> Before the introduction of cpuset partition, writing to cpuset.cpus will only
> fail if the cpu list
> is invalid like containing CPUs outside of the valid cpu range. What I mean
> by "never-fail" is that
> if the cpu list is valid, the write action should not fail. The rule is not
> explicitly stated in the
> documentation, but it is a pre-existing behavior which we should try to keep
> to avoid breaking
> existing applications.
>
There are two conditions that can cause a cpuset.cpus write operation to fail:
ENOSPC (No space left
on device) and EBUSY.
I just want to ensure the behavior aligns with our design intent.
Consider this example:
# cd /sys/fs/cgroup/
# mkdir test
# echo 1 > test/cpuset.cpus
# echo $$ > test/cgroup.procs
# echo 0 > /sys/devices/system/cpu/cpu1/online
# echo > test/cpuset.cpus
-bash: echo: write error: No space left on device
In cgroups v2, if the test cgroup becomes empty, it could inherit the parent's
effective CPUs. My
question is: Should we still fail to clear cpuset.cpus (returning an error)
when the cgroup is
populated?
> The exclusive CPU constraint does not apply to cpuset.cpus. It only applies
> when setting
> cpuset.cpus.exclusive wrt to other cpuset.cpus.exclusive* in sibling cpusets.
> So I will not say one
> has higher priority than the other.
>
> Cheers,
> Longman
>
--
Best regards,
Ridong
