On 2025/11/19 21:20, Michal Koutný wrote:
> On Wed, Nov 19, 2025 at 06:57:49PM +0800, Sun Shaojie <[email protected]>
> wrote:
>> Currently, when setting a cpuset's cpuset.cpus to a value that conflicts
>> with its sibling partition, the sibling's partition state becomes invalid.
>> However, this invalidation is often unnecessary. If the cpuset being
>> modified is exclusive, it should invalidate itself upon conflict.
>>
>> This patch applies only to the following two cases：
>>
>> Assume the machine has 4 CPUs (0-3).
>>
>> root cgroup
>> / \
>> A1 B1
>>
>> Case 1: A1 is exclusive, B1 is non-exclusive, set B1's cpuset.cpus
>>
>> Table 1.1: Before applying this patch
>> Step | A1's prstate | B1's prstate |
>> #1> echo "0-1" > A1/cpuset.cpus | member | member |
>> #2> echo "root" > A1/cpuset.cpus.partition | root | member |
>> #3> echo "0" > B1/cpuset.cpus | root invalid | member |
>>
>> After step #3, A1 changes from "root" to "root invalid" because its CPUs
>> (0-1) overlap with those requested by B1 (0). However, B1 can actually
>> use CPUs 2-3(from B1's parent), so it would be more reasonable for A1 to
>> remain as "root."
>>
>> Table 1.2: After applying this patch
>> Step | A1's prstate | B1's prstate |
>> #1> echo "0-1" > A1/cpuset.cpus | member | member |
>> #2> echo "root" > A1/cpuset.cpus.partition | root | member |
>> #3> echo "0" > B1/cpuset.cpus | root | member |
>>
>> Case 2: Both A1 and B1 are exclusive, set B1's cpuset.cpus
>
> (Thanks for working this out, Shaojie.)
>
>>
>> Table 2.1: Before applying this patch
>> Step | A1's prstate | B1's prstate |
>> #1> echo "0-1" > A1/cpuset.cpus | member | member |
>> #2> echo "root" > A1/cpuset.cpus.partition | root | member |
>> #3> echo "2" > B1/cpuset.cpus | root | member |
>> #4> echo "root" > B1/cpuset.cpus.partition | root | root |
>> #5> echo "1-2" > B1/cpuset.cpus | root invalid | root invalid |
>>
>> After step #4, B1 can exclusively use CPU 2. Therefore, at step #5,
>> regardless of what conflicting value B1 writes to cpuset.cpus, it will
>> always have at least CPU 2 available. This makes it unnecessary to mark
>> A1 as "root invalid".
>>
>> Table 2.2: After applying this patch
>> Step | A1's prstate | B1's prstate |
>> #1> echo "0-1" > A1/cpuset.cpus | member | member |
>> #2> echo "root" > A1/cpuset.cpus.partition | root | member |
>> #3> echo "2" > B1/cpuset.cpus | root | member |
>> #4> echo "root" > B1/cpuset.cpus.partition | root | root |
>> #5> echo "1-2" > B1/cpuset.cpus | root | root invalid |
>>
>> In summary, regardless of how B1 configures its cpuset.cpus, there will
>> always be available CPUs in B1's cpuset.cpus.effective. Therefore, there
>> is no need to change A1 from "root" to "root invalid".
>
> Admittedly, I don't like this change because it relies on implicit
> preference ordering between siblings (here first comes, first served)
Agree. If we only invalidate the latter one, I think regardless of the
implementation approach, we
may end up with different results depending on the order of operations.
> and so the effective config cannot be derived just from the applied
> values :-/
>
> Do you actually want to achieve this or is it an implementation
> side-effect of the Case 1 scenario that you want to achieve?
>
>
> Thanks,
> Michal
--
Best regards,
Ridong
