Re: [PATCH cgroup/for-6.20 v4 4/5] cgroup/cpuset: Don't invalidate sibling partitions on cpuset.cpus conflict

From: Waiman Long

Date: Mon Jan 12 2026 - 11:02:35 EST

On 1/12/26 10:15 AM, Waiman Long wrote:
On 1/12/26 10:08 AM, Michal Koutný wrote:
On Mon, Jan 12, 2026 at 09:51:28AM -0500, Waiman Long <llong@xxxxxxxxxx> wrote:
Sorry, I might have missed this comment of yours. The
"cpuset.cpus.exclusive" file lists all the CPUs that can be granted to its
children as exclusive CPUs. The cgroup root is an implicit partition root
where all its CPUs can be granted to its children whether they are online or
offline. "cpuset.cpus.effective" OTOH ignores the offline CPUs as well as
exclusive CPUs that have been passed down to existing descendant partition
roots so it may differ from the implicit "cpuset.cpus.exclusive".
Howewer, there's no "cpuset.cpus" configurable nor visible on the root
cgroup. So possibly drop this hunk altogether for simplicity?

Ah, you are right. I thought there was a read-only copy in cgroup root. Will correct that.

Below is the doc diff between v4 and v5:

diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst
index a3446db96cea..28613c0e1c90 100644
--- a/Documentation/admin-guide/cgroup-v2.rst
+++ b/Documentation/admin-guide/cgroup-v2.rst
@@ -2641,9 +2641,10 @@ Cpuset Interface Files

     The root cgroup is always a partition root and its state cannot
     be changed.  All other non-root cgroups start out as "member".
-    Even though the "cpuset.cpus.exclusive*" control files are not
-    present in the root cgroup, they are implicitly the same as
-    "cpuset.cpus".
+    Even though the "cpuset.cpus.exclusive*" and "cpuset.cpus"
+    control files are not present in the root cgroup, they are
+    implicitly the same as the "/sys/devices/system/cpu/possible"
+    sysfs file.

     When set to "root", the current cgroup is the root of a new
     partition or scheduling domain.  The set of exclusive CPUs is

Cheers,
Longman