[PATCH-next v3 0/3] cgroup/cpuset: Support multiple destination cpusets for cpuset_*attach()

Waiman Long posted 3 patches 1 week, 5 days ago
kernel/cgroup/cpuset.c                       | 131 ++++++----
tools/testing/selftests/cgroup/test_cpuset.c | 243 +++++++++++++++++++
2 files changed, 321 insertions(+), 53 deletions(-)
[PATCH-next v3 0/3] cgroup/cpuset: Support multiple destination cpusets for cpuset_*attach()
Posted by Waiman Long 1 week, 5 days ago
 v3:
  - Swap the first 2 patches as the original patch 1 can introduce serious bug
    without patch 2. Doing patch 2 first will be less problematic.

 v2: https://lore.kernel.org/lkml/20260712150127.236790-1-longman@redhat.com
  - Make sure that attach_ctx.old_cs won't be set to a source cpuset that is
    also the destination cpuset.

 v1: https://lore.kernel.org/lkml/20260711020540.176740-1-longman@redhat.com

This is a follow-up patch series to [1] to properly handle a special case
for cpuset task migration operation where the source and destination
cpusets are the same.

Patch 1 enables cpuset_*attach() to handle the case where there are many
destination cpusets from enabling cpuset controller. Patch 2 handles
those tasks that have the same source and destination cpuset by skipping
them as they are not migrating with respect to cpuset. Patch 3 adds a
new test case into test_cpuset to test proper handling of cpu affinity
when cpuset controller is disabled.

[1] https://lore.kernel.org/lkml/20260702214757.579012-1-longman@redhat.com

Michal Koutný (1):
  selftests/cgroup: Add test for cpuset affinity on controller disable

Waiman Long (2):
  cgroup/cpuset: Support multiple destination cpusets for
    cpuset_*attach()
  cgroup/cpuset: Handle the special case of non-moving tasks in
    cpuset_can_attach()

 kernel/cgroup/cpuset.c                       | 131 ++++++----
 tools/testing/selftests/cgroup/test_cpuset.c | 243 +++++++++++++++++++
 2 files changed, 321 insertions(+), 53 deletions(-)

-- 
2.55.0

Re: [PATCH-next v3 0/3] cgroup/cpuset: Support multiple destination cpusets for cpuset_*attach()
Posted by Ridong Chen 1 week, 4 days ago

On 7/13/2026 7:55 AM, Waiman Long wrote:
>   v3:
>    - Swap the first 2 patches as the original patch 1 can introduce serious bug
>      without patch 2. Doing patch 2 first will be less problematic.
> 

Would it make sense to squash these two patches into one?

>   v2: https://lore.kernel.org/lkml/20260712150127.236790-1-longman@redhat.com
>    - Make sure that attach_ctx.old_cs won't be set to a source cpuset that is
>      also the destination cpuset.
> 
>   v1: https://lore.kernel.org/lkml/20260711020540.176740-1-longman@redhat.com
> 
> This is a follow-up patch series to [1] to properly handle a special case
> for cpuset task migration operation where the source and destination
> cpusets are the same.
> 
> Patch 1 enables cpuset_*attach() to handle the case where there are many
> destination cpusets from enabling cpuset controller. Patch 2 handles
> those tasks that have the same source and destination cpuset by skipping
> them as they are not migrating with respect to cpuset. Patch 3 adds a
> new test case into test_cpuset to test proper handling of cpu affinity
> when cpuset controller is disabled.
> 
> [1] https://lore.kernel.org/lkml/20260702214757.579012-1-longman@redhat.com
> 
> Michal Koutný (1):
>    selftests/cgroup: Add test for cpuset affinity on controller disable
> 
> Waiman Long (2):
>    cgroup/cpuset: Support multiple destination cpusets for
>      cpuset_*attach()
>    cgroup/cpuset: Handle the special case of non-moving tasks in
>      cpuset_can_attach()
> 
>   kernel/cgroup/cpuset.c                       | 131 ++++++----
>   tools/testing/selftests/cgroup/test_cpuset.c | 243 +++++++++++++++++++
>   2 files changed, 321 insertions(+), 53 deletions(-)
> 

-- 
Best regards
Ridong

Re: [PATCH-next v3 0/3] cgroup/cpuset: Support multiple destination cpusets for cpuset_*attach()
Posted by Waiman Long 1 week, 2 days ago
On 7/14/26 4:57 AM, Ridong Chen wrote:
>
>
> On 7/13/2026 7:55 AM, Waiman Long wrote:
>>   v3:
>>    - Swap the first 2 patches as the original patch 1 can introduce 
>> serious bug
>>      without patch 2. Doing patch 2 first will be less problematic.
>>
>
> Would it make sense to squash these two patches into one?

They are unrelated issues. That is why they are different patches.

Cheers,
Longman