[PATCH 0/2] docs: cgroup-v2: Correct cpuset CPU descriptions

[PATCH 0/2] docs: cgroup-v2: Correct cpuset CPU descriptions

[Guopeng Zhang]

From: Guopeng Zhang <zhangguopeng@kylinos.cn>

The cpuset interface documentation says cpuset.cpus.isolated is empty
unless an isolated partition exists, omitting CPUs isolated at boot with
isolcpus=domain. Its cpuset.cpus.effective description also assumes CPUs
come from the immediate parent and are normally a subset of
cpuset.cpus, which is not always true for valid non-root partition roots.

Update both descriptions to match the existing behavior.

Guopeng Zhang (2):
  docs: cgroup-v2: Describe boot-isolated CPUs in cpuset.cpus.isolated
  docs: cgroup-v2: Describe effective CPUs of partition roots

 Documentation/admin-guide/cgroup-v2.rst | 37 ++++++++++++++++---------
 1 file changed, 24 insertions(+), 13 deletions(-)

-- 
2.43.0

[PATCH 1/2] docs: cgroup-v2: Describe boot-isolated CPUs in cpuset.cpus.isolated

[Guopeng Zhang]

From: Guopeng Zhang <zhangguopeng@kylinos.cn>

cpuset.cpus.isolated is documented as empty when no isolated partition
exists. This is not true when CPUs are isolated at boot with
isolcpus=domain. cpuset_init() adds those CPUs to the isolated mask,
and isolcpus=<cpu-list> uses domain isolation by default. They remain
listed after a partition using them is released.

Document the boot-isolated CPUs as well.

Signed-off-by: Guopeng Zhang <zhangguopeng@kylinos.cn>
---
 Documentation/admin-guide/cgroup-v2.rst | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst
index 2ec582985b5b..272e9f2432bd 100644
--- a/Documentation/admin-guide/cgroup-v2.rst
+++ b/Documentation/admin-guide/cgroup-v2.rst
@@ -2625,9 +2625,11 @@ Cpuset Interface Files
   cpuset.cpus.isolated
 	A read-only and root cgroup only multiple values file.
 
-	This file shows the set of all isolated CPUs used in existing
-	isolated partitions. It will be empty if no isolated partition
-	is created.
+	This file shows CPUs isolated from scheduler domains by
+	isolated cpuset partitions or at boot with "isolcpus=domain"
+	(including the default "isolcpus=<cpu-list>" form).  CPUs
+	isolated at boot remain listed after any partition using them
+	is released.
 
   cpuset.cpus.partition
 	A read-write single value file which exists on non-root
-- 
2.43.0

Re: [PATCH 1/2] docs: cgroup-v2: Describe boot-isolated CPUs in cpuset.cpus.isolated

[Ridong Chen]

On 9/18/2026 6:23 PM, Guopeng Zhang wrote:
> From: Guopeng Zhang <zhangguopeng@kylinos.cn>
> 
> cpuset.cpus.isolated is documented as empty when no isolated partition
> exists. This is not true when CPUs are isolated at boot with
> isolcpus=domain. cpuset_init() adds those CPUs to the isolated mask,
> and isolcpus=<cpu-list> uses domain isolation by default. They remain
> listed after a partition using them is released.
> 
> Document the boot-isolated CPUs as well.
> 
> Signed-off-by: Guopeng Zhang <zhangguopeng@kylinos.cn>
> ---
>   Documentation/admin-guide/cgroup-v2.rst | 8 +++++---
>   1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst
> index 2ec582985b5b..272e9f2432bd 100644
> --- a/Documentation/admin-guide/cgroup-v2.rst
> +++ b/Documentation/admin-guide/cgroup-v2.rst
> @@ -2625,9 +2625,11 @@ Cpuset Interface Files
>     cpuset.cpus.isolated
>   	A read-only and root cgroup only multiple values file.
>   
> -	This file shows the set of all isolated CPUs used in existing
> -	isolated partitions. It will be empty if no isolated partition
> -	is created.
> +	This file shows CPUs isolated from scheduler domains by
> +	isolated cpuset partitions or at boot with "isolcpus=domain"
> +	(including the default "isolcpus=<cpu-list>" form).  CPUs
> +	isolated at boot remain listed after any partition using them
> +	is released.
>   
>     cpuset.cpus.partition
>   	A read-write single value file which exists on non-root

Could we keep that terminology and avoid repeating "isolated"? Something like:

       This file shows the set of all isolated CPUs used in existing
       isolated partitions or isolated at boot time via "isolcpus".
       The latter remain listed even after any partition using them
       is released.

With that:

Reviewed-by: Ridong Chen <ridong.chen@linux.dev>

-- 
Best regards
Ridong

Re: [PATCH 1/2] docs: cgroup-v2: Describe boot-isolated CPUs in cpuset.cpus.isolated

[Guopeng Zhang]

在 2026/9/21 12:29, Ridong Chen 写道:
> 
> 
> On 9/18/2026 6:23 PM, Guopeng Zhang wrote:
>> From: Guopeng Zhang <zhangguopeng@kylinos.cn>
>>
>> cpuset.cpus.isolated is documented as empty when no isolated partition
>> exists. This is not true when CPUs are isolated at boot with
>> isolcpus=domain. cpuset_init() adds those CPUs to the isolated mask,
>> and isolcpus=<cpu-list> uses domain isolation by default. They remain
>> listed after a partition using them is released.
>>
>> Document the boot-isolated CPUs as well.
>>
>> Signed-off-by: Guopeng Zhang <zhangguopeng@kylinos.cn>
>> ---
>>   Documentation/admin-guide/cgroup-v2.rst | 8 +++++---
>>   1 file changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst
>> index 2ec582985b5b..272e9f2432bd 100644
>> --- a/Documentation/admin-guide/cgroup-v2.rst
>> +++ b/Documentation/admin-guide/cgroup-v2.rst
>> @@ -2625,9 +2625,11 @@ Cpuset Interface Files
>>     cpuset.cpus.isolated
>>       A read-only and root cgroup only multiple values file.
>>   -    This file shows the set of all isolated CPUs used in existing
>> -    isolated partitions. It will be empty if no isolated partition
>> -    is created.
>> +    This file shows CPUs isolated from scheduler domains by
>> +    isolated cpuset partitions or at boot with "isolcpus=domain"
>> +    (including the default "isolcpus=<cpu-list>" form).  CPUs
>> +    isolated at boot remain listed after any partition using them
>> +    is released.
>>       cpuset.cpus.partition
>>       A read-write single value file which exists on non-root
> 
> Could we keep that terminology and avoid repeating "isolated"? Something like:
> 
>       This file shows the set of all isolated CPUs used in existing
>       isolated partitions or isolated at boot time via "isolcpus".
>       The latter remain listed even after any partition using them
>       is released.
> 
> With that:
> 
> Reviewed-by: Ridong Chen <ridong.chen@linux.dev>
> 

Thanks for the suggestion. That reads better.

I'll make one small change and use "the domain flag of isolcpus" here, since isolcpus also supports the nohz and managed_irq flags. I'll update the wording in v2 and add your Reviewed-by.

Thanks,
Guopeng

[PATCH 2/2] docs: cgroup-v2: Describe effective CPUs of partition roots

[Guopeng Zhang]

From: Guopeng Zhang <zhangguopeng@kylinos.cn>

The cpuset.cpus.effective description says that the effective CPUs are
granted by the parent and are normally a subset of cpuset.cpus. This
does not always hold for a valid non-root partition root. Its effective
CPUs are the active CPUs in cpuset.cpus.exclusive.effective after CPUs
assigned to valid child partition roots are removed.

If cpuset.cpus.exclusive differs from cpuset.cpus, the effective CPUs
may therefore be outside cpuset.cpus. Remote partitions also do not
necessarily get their CPUs from their immediate parent.

Signed-off-by: Guopeng Zhang <zhangguopeng@kylinos.cn>
---
 Documentation/admin-guide/cgroup-v2.rst | 29 ++++++++++++++++---------
 1 file changed, 19 insertions(+), 10 deletions(-)

diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst
index 272e9f2432bd..49ce8deb4115 100644
--- a/Documentation/admin-guide/cgroup-v2.rst
+++ b/Documentation/admin-guide/cgroup-v2.rst
@@ -2505,16 +2505,25 @@ Cpuset Interface Files
 	A read-only multiple values file which exists on all
 	cpuset-enabled cgroups.
 
-	It lists the onlined CPUs that are actually granted to this
-	cgroup by its parent.  These CPUs are allowed to be used by
-	tasks within the current cgroup.
-
-	If "cpuset.cpus" is empty, the "cpuset.cpus.effective" file shows
-	all the CPUs from the parent cgroup that can be available to
-	be used by this cgroup.  Otherwise, it should be a subset of
-	"cpuset.cpus" unless none of the CPUs listed in "cpuset.cpus"
-	can be granted.  In this case, it will be treated just like an
-	empty "cpuset.cpus".
+	It lists the active CPUs available to tasks in this cgroup.
+
+	For a cgroup that is not a valid partition root, an empty
+	"cpuset.cpus" makes "cpuset.cpus.effective" show all CPUs
+	available from the parent cgroup.  Otherwise, it is a subset
+	of "cpuset.cpus" unless none of the requested CPUs can be
+	granted.  In that case, it is treated like an empty
+	"cpuset.cpus".
+
+	For a valid non-root partition root, "cpuset.cpus.effective" contains
+	the active CPUs from "cpuset.cpus.exclusive.effective" except
+	those granted to valid child partition roots.  If
+	"cpuset.cpus.exclusive" is set to a value different from
+	"cpuset.cpus", the effective CPUs need not be a subset of
+	"cpuset.cpus".  For example, if CPUs 2-5 are active,
+	available, and not assigned to a valid child partition root,
+	a partition root with "cpuset.cpus" set to "0-3" and
+	"cpuset.cpus.exclusive" set to "2-5" has "2-5" in
+	"cpuset.cpus.effective".
 
 	Its value will be affected by CPU hotplug events.
 
-- 
2.43.0

Re: [PATCH 2/2] docs: cgroup-v2: Describe effective CPUs of partition roots

[Ridong Chen]

On 9/18/2026 6:23 PM, Guopeng Zhang wrote:
> From: Guopeng Zhang <zhangguopeng@kylinos.cn>
> 
> The cpuset.cpus.effective description says that the effective CPUs are
> granted by the parent and are normally a subset of cpuset.cpus. This
> does not always hold for a valid non-root partition root. Its effective
> CPUs are the active CPUs in cpuset.cpus.exclusive.effective after CPUs
> assigned to valid child partition roots are removed.
> 
> If cpuset.cpus.exclusive differs from cpuset.cpus, the effective CPUs
> may therefore be outside cpuset.cpus. Remote partitions also do not
> necessarily get their CPUs from their immediate parent.
> 
> Signed-off-by: Guopeng Zhang <zhangguopeng@kylinos.cn>
> ---
>   Documentation/admin-guide/cgroup-v2.rst | 29 ++++++++++++++++---------
>   1 file changed, 19 insertions(+), 10 deletions(-)
> 
> diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst
> index 272e9f2432bd..49ce8deb4115 100644
> --- a/Documentation/admin-guide/cgroup-v2.rst
> +++ b/Documentation/admin-guide/cgroup-v2.rst
> @@ -2505,16 +2505,25 @@ Cpuset Interface Files
>   	A read-only multiple values file which exists on all
>   	cpuset-enabled cgroups.
>   
> -	It lists the onlined CPUs that are actually granted to this
> -	cgroup by its parent.  These CPUs are allowed to be used by
> -	tasks within the current cgroup.
> -
> -	If "cpuset.cpus" is empty, the "cpuset.cpus.effective" file shows
> -	all the CPUs from the parent cgroup that can be available to
> -	be used by this cgroup.  Otherwise, it should be a subset of
> -	"cpuset.cpus" unless none of the CPUs listed in "cpuset.cpus"
> -	can be granted.  In this case, it will be treated just like an
> -	empty "cpuset.cpus".
> +	It lists the active CPUs available to tasks in this cgroup.
> +
> +	For a cgroup that is not a valid partition root, an empty
> +	"cpuset.cpus" makes "cpuset.cpus.effective" show all CPUs
> +	available from the parent cgroup.  Otherwise, it is a subset
> +	of "cpuset.cpus" unless none of the requested CPUs can be
> +	granted.  In that case, it is treated like an empty
> +	"cpuset.cpus".
> +
> +	For a valid non-root partition root, "cpuset.cpus.effective" contains
> +	the active CPUs from "cpuset.cpus.exclusive.effective" except
> +	those granted to valid child partition roots.  If
> +	"cpuset.cpus.exclusive" is set to a value different from
> +	"cpuset.cpus", the effective CPUs need not be a subset of
> +	"cpuset.cpus".  For example, if CPUs 2-5 are active,
> +	available, and not assigned to a valid child partition root,
> +	a partition root with "cpuset.cpus" set to "0-3" and
> +	"cpuset.cpus.exclusive" set to "2-5" has "2-5" in
> +	"cpuset.cpus.effective".
>   
>   	Its value will be affected by CPU hotplug events.
>   

Hi Guopeng,

Thank you for your effort.

May I suggest adding a simple diagram to help clarify the relationship? 
Similarly, could you add a simple diagram to illustrate the relationship? 
Something like:

```
   A(cpu,memory) - B(memory) - C()
                             \ D()
```

I mean adding one diagram for the valid root case and another for the others 
(member / invalid root), so it becomes easier to see how they differ. What do 
you think?

-- 
Best regards
Ridong

Re: [PATCH 2/2] docs: cgroup-v2: Describe effective CPUs of partition roots

[Guopeng Zhang]

在 2026/9/21 14:38, Ridong Chen 写道:
> 
> 
> On 9/18/2026 6:23 PM, Guopeng Zhang wrote:
>> From: Guopeng Zhang <zhangguopeng@kylinos.cn>
>>
>> The cpuset.cpus.effective description says that the effective CPUs are
>> granted by the parent and are normally a subset of cpuset.cpus. This
>> does not always hold for a valid non-root partition root. Its effective
>> CPUs are the active CPUs in cpuset.cpus.exclusive.effective after CPUs
>> assigned to valid child partition roots are removed.
>>
>> If cpuset.cpus.exclusive differs from cpuset.cpus, the effective CPUs
>> may therefore be outside cpuset.cpus. Remote partitions also do not
>> necessarily get their CPUs from their immediate parent.
>>
>> Signed-off-by: Guopeng Zhang <zhangguopeng@kylinos.cn>
>> ---
>>   Documentation/admin-guide/cgroup-v2.rst | 29 ++++++++++++++++---------
>>   1 file changed, 19 insertions(+), 10 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst
>> index 272e9f2432bd..49ce8deb4115 100644
>> --- a/Documentation/admin-guide/cgroup-v2.rst
>> +++ b/Documentation/admin-guide/cgroup-v2.rst
>> @@ -2505,16 +2505,25 @@ Cpuset Interface Files
>>       A read-only multiple values file which exists on all
>>       cpuset-enabled cgroups.
>>   -    It lists the onlined CPUs that are actually granted to this
>> -    cgroup by its parent.  These CPUs are allowed to be used by
>> -    tasks within the current cgroup.
>> -
>> -    If "cpuset.cpus" is empty, the "cpuset.cpus.effective" file shows
>> -    all the CPUs from the parent cgroup that can be available to
>> -    be used by this cgroup.  Otherwise, it should be a subset of
>> -    "cpuset.cpus" unless none of the CPUs listed in "cpuset.cpus"
>> -    can be granted.  In this case, it will be treated just like an
>> -    empty "cpuset.cpus".
>> +    It lists the active CPUs available to tasks in this cgroup.
>> +
>> +    For a cgroup that is not a valid partition root, an empty
>> +    "cpuset.cpus" makes "cpuset.cpus.effective" show all CPUs
>> +    available from the parent cgroup.  Otherwise, it is a subset
>> +    of "cpuset.cpus" unless none of the requested CPUs can be
>> +    granted.  In that case, it is treated like an empty
>> +    "cpuset.cpus".
>> +
>> +    For a valid non-root partition root, "cpuset.cpus.effective" contains
>> +    the active CPUs from "cpuset.cpus.exclusive.effective" except
>> +    those granted to valid child partition roots.  If
>> +    "cpuset.cpus.exclusive" is set to a value different from
>> +    "cpuset.cpus", the effective CPUs need not be a subset of
>> +    "cpuset.cpus".  For example, if CPUs 2-5 are active,
>> +    available, and not assigned to a valid child partition root,
>> +    a partition root with "cpuset.cpus" set to "0-3" and
>> +    "cpuset.cpus.exclusive" set to "2-5" has "2-5" in
>> +    "cpuset.cpus.effective".
>>         Its value will be affected by CPU hotplug events.
>>   
> 
> Hi Guopeng,
> 
> Thank you for your effort.
> 
> May I suggest adding a simple diagram to help clarify the relationship? Similarly, could you add a simple diagram to illustrate the relationship? Something like:
> 
> ```
>   A(cpu,memory) - B(memory) - C()
>                             \ D()
> ```
> 
> I mean adding one diagram for the valid root case and another for the others (member / invalid root), so it becomes easier to see how they differ. What do you think?
> 

Thanks for the suggestion. I agree that a simple diagram would make this easier to understand.

I'll add the diagrams in v2.

Thanks,
Guopeng