On 11/19/25 5:57 AM, Sun Shaojie 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

  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".

All other cases remain unaffected. For example, cgroup-v1.

This patch is relatively simple. As others have pointed out, there are inconsistency depending on the operation ordering.

In the example above, the final configuration is A1:0-1 & B1:1-2. As the cpu lists overlap, we can't have both of them as valid partition roots. So either one of A1 or B1 is valid or they are both invalid. The current code makes them both invalid no matter the operation ordering.  This patch will make one of them valid given the operation ordering above. To minimize partition invalidation, we will have to live with the fact that it will be first-come first-serve as noted by Michal. I am not against this, we just have to document it. However, the following operation order will still make both of them invalid:

# echo "0-1" >A1/cpuset.cpus # echo "2" > B1/cpuset.cpus # echo "1-2" > B1/cpuset.cpus # echo "root" > A1/cpuset.cpus.partition # echo "root" > B1/cpuset.cpus.partition

To follow the "first-come first-serve" rule, A1 should be valid and B1 invalid. That is the inconsistency with your current patch. To fix that, we still need to relax the overlap checking rule similar to your v4 patch.

Cheers,
Longman


Reply via email to