From: Chen Ridong <chenridong@huawei.com>

The current local partition implementation consolidates all operations
(enable, disable, invalidate, and update) within the large
update_parent_effective_cpumask() function, which exceeds 300 lines.
This monolithic approach has become increasingly difficult to understand
and maintain. Additionally, partition-related fields are updated in
multiple locations, leading to redundant code and potential corner case
oversights.

This patch series refactors the local partition logic by separating
operations into dedicated functions: local_partition_enable(),
local_partition_disable(), and local_partition_update(), creating
symmetry with the existing remote partition infrastructure.

The series is organized as follows:

1. Infrastructure Preparation (Patches 1-2):
   - Code cleanup and preparation for the refactoring work

2. Core Partition Operations (Patches 3-5):
   - Factor out partition_enable(), partition_disable(), and
     partition_update() functions from remote partition operations

3. Local Partition Implementation (Patches 6-9):
   - Separate update_parent_effective_cpumask() into dedicated functions:
     * local_partition_enable()
     * local_partition_disable()
     * local_partition_invalidate()
     * local_partition_update()

4. Optimization and Cleanup (Patches 10-16):
   - Remove redundant partition-related operations
   - Additional optimizations based on the new architecture

Key improvements:
- Centralized management of partition-related fields (partition_root_state,
  prs_err, nr_subparts, remote_sibling, effective_xcpus) within the
  partition_enable/disable/update functions
- Consistent operation patterns for both local and remote partitions
  with type-specific validation checks
- Fixed bug where isolcpus remained in root partition after isolated
  partition transitioned to root

Chen Ridong (16):
  cpuset: use update_partition_sd_lb in update_cpumasks_hier
  cpuset: generalize validate_partition() interface
  cpuset: factor out partition_enable() function
  cpuset: factor out partition_disable() function
  cpuset: factor out partition_update() function
  cpuset: introduce local_partition_enable()
  cpuset: introduce local_partition_disable()
  cpuset: introduce local_partition_invalidate()
  cpuset: introduce local_partition_update()
  cpuset: remove redundant partition field updates
  cpuset: simplify partition update logic for hotplug tasks
  cpuset: unify local partition disable and invalidate
  cpuset: use partition_disable for compute_partition_effective_cpumask
  cpuset: fix isolcpus stay in root when isolated partition changes to
    root
  cpuset: use partition_disable for update_prstate
  cpuset: remove prs_err clear when notify_partition_change

 kernel/cgroup/cpuset.c | 907 ++++++++++++++++++-----------------------
 1 file changed, 408 insertions(+), 499 deletions(-)

-- 
2.34.1

On 2025/9/28 15:12, Chen Ridong wrote:
> From: Chen Ridong <chenridong@huawei.com>
> 
> The current local partition implementation consolidates all operations
> (enable, disable, invalidate, and update) within the large
> update_parent_effective_cpumask() function, which exceeds 300 lines.
> This monolithic approach has become increasingly difficult to understand
> and maintain. Additionally, partition-related fields are updated in
> multiple locations, leading to redundant code and potential corner case
> oversights.
> 
> This patch series refactors the local partition logic by separating
> operations into dedicated functions: local_partition_enable(),
> local_partition_disable(), and local_partition_update(), creating
> symmetry with the existing remote partition infrastructure.
> 
> The series is organized as follows:
> 
> 1. Infrastructure Preparation (Patches 1-2):
>    - Code cleanup and preparation for the refactoring work
> 
> 2. Core Partition Operations (Patches 3-5):
>    - Factor out partition_enable(), partition_disable(), and
>      partition_update() functions from remote partition operations
> 
> 3. Local Partition Implementation (Patches 6-9):
>    - Separate update_parent_effective_cpumask() into dedicated functions:
>      * local_partition_enable()
>      * local_partition_disable()
>      * local_partition_invalidate()
>      * local_partition_update()
> 
> 4. Optimization and Cleanup (Patches 10-16):
>    - Remove redundant partition-related operations
>    - Additional optimizations based on the new architecture
> 
> Key improvements:
> - Centralized management of partition-related fields (partition_root_state,
>   prs_err, nr_subparts, remote_sibling, effective_xcpus) within the
>   partition_enable/disable/update functions
> - Consistent operation patterns for both local and remote partitions
>   with type-specific validation checks
> - Fixed bug where isolcpus remained in root partition after isolated
>   partition transitioned to root
> 
> Chen Ridong (16):
>   cpuset: use update_partition_sd_lb in update_cpumasks_hier
>   cpuset: generalize validate_partition() interface
>   cpuset: factor out partition_enable() function
>   cpuset: factor out partition_disable() function
>   cpuset: factor out partition_update() function
>   cpuset: introduce local_partition_enable()
>   cpuset: introduce local_partition_disable()
>   cpuset: introduce local_partition_invalidate()
>   cpuset: introduce local_partition_update()
>   cpuset: remove redundant partition field updates
>   cpuset: simplify partition update logic for hotplug tasks
>   cpuset: unify local partition disable and invalidate
>   cpuset: use partition_disable for compute_partition_effective_cpumask
>   cpuset: fix isolcpus stay in root when isolated partition changes to
>     root
>   cpuset: use partition_disable for update_prstate
>   cpuset: remove prs_err clear when notify_partition_change
> 
>  kernel/cgroup/cpuset.c | 907 ++++++++++++++++++-----------------------
>  1 file changed, 408 insertions(+), 499 deletions(-)
> 

+cc cgroups@vger.kernel.org

-- 
Best regards,
Ridong

On 9/28/25 3:12 AM, Chen Ridong wrote:
> From: Chen Ridong <chenridong@huawei.com>
>
> The current local partition implementation consolidates all operations
> (enable, disable, invalidate, and update) within the large
> update_parent_effective_cpumask() function, which exceeds 300 lines.
> This monolithic approach has become increasingly difficult to understand
> and maintain. Additionally, partition-related fields are updated in
> multiple locations, leading to redundant code and potential corner case
> oversights.
>
> This patch series refactors the local partition logic by separating
> operations into dedicated functions: local_partition_enable(),
> local_partition_disable(), and local_partition_update(), creating
> symmetry with the existing remote partition infrastructure.
>
> The series is organized as follows:
>
> 1. Infrastructure Preparation (Patches 1-2):
>     - Code cleanup and preparation for the refactoring work
>
> 2. Core Partition Operations (Patches 3-5):
>     - Factor out partition_enable(), partition_disable(), and
>       partition_update() functions from remote partition operations
>
> 3. Local Partition Implementation (Patches 6-9):
>     - Separate update_parent_effective_cpumask() into dedicated functions:
>       * local_partition_enable()
>       * local_partition_disable()
>       * local_partition_invalidate()
>       * local_partition_update()
>
> 4. Optimization and Cleanup (Patches 10-16):
>     - Remove redundant partition-related operations
>     - Additional optimizations based on the new architecture
>
> Key improvements:
> - Centralized management of partition-related fields (partition_root_state,
>    prs_err, nr_subparts, remote_sibling, effective_xcpus) within the
>    partition_enable/disable/update functions
> - Consistent operation patterns for both local and remote partitions
>    with type-specific validation checks
> - Fixed bug where isolcpus remained in root partition after isolated
>    partition transitioned to root

You are really active in restructuring the cpuset code. However, the 
next merge window for v6.18 is going to open later today or tomorrow. I 
will start reviewing this patch series once the merge window closes 2 
weeks later.

Cheers,
Longman

> Chen Ridong (16):
>    cpuset: use update_partition_sd_lb in update_cpumasks_hier
>    cpuset: generalize validate_partition() interface
>    cpuset: factor out partition_enable() function
>    cpuset: factor out partition_disable() function
>    cpuset: factor out partition_update() function
>    cpuset: introduce local_partition_enable()
>    cpuset: introduce local_partition_disable()
>    cpuset: introduce local_partition_invalidate()
>    cpuset: introduce local_partition_update()
>    cpuset: remove redundant partition field updates
>    cpuset: simplify partition update logic for hotplug tasks
>    cpuset: unify local partition disable and invalidate
>    cpuset: use partition_disable for compute_partition_effective_cpumask
>    cpuset: fix isolcpus stay in root when isolated partition changes to
>      root
>    cpuset: use partition_disable for update_prstate
>    cpuset: remove prs_err clear when notify_partition_change
>
>   kernel/cgroup/cpuset.c | 907 ++++++++++++++++++-----------------------
>   1 file changed, 408 insertions(+), 499 deletions(-)
>

On 2025/9/29 0:00, Waiman Long wrote:
> On 9/28/25 3:12 AM, Chen Ridong wrote:
>> From: Chen Ridong <chenridong@huawei.com>
>>
>> The current local partition implementation consolidates all operations
>> (enable, disable, invalidate, and update) within the large
>> update_parent_effective_cpumask() function, which exceeds 300 lines.
>> This monolithic approach has become increasingly difficult to understand
>> and maintain. Additionally, partition-related fields are updated in
>> multiple locations, leading to redundant code and potential corner case
>> oversights.
>>
>> This patch series refactors the local partition logic by separating
>> operations into dedicated functions: local_partition_enable(),
>> local_partition_disable(), and local_partition_update(), creating
>> symmetry with the existing remote partition infrastructure.
>>
>> The series is organized as follows:
>>
>> 1. Infrastructure Preparation (Patches 1-2):
>>     - Code cleanup and preparation for the refactoring work
>>
>> 2. Core Partition Operations (Patches 3-5):
>>     - Factor out partition_enable(), partition_disable(), and
>>       partition_update() functions from remote partition operations
>>
>> 3. Local Partition Implementation (Patches 6-9):
>>     - Separate update_parent_effective_cpumask() into dedicated functions:
>>       * local_partition_enable()
>>       * local_partition_disable()
>>       * local_partition_invalidate()
>>       * local_partition_update()
>>
>> 4. Optimization and Cleanup (Patches 10-16):
>>     - Remove redundant partition-related operations
>>     - Additional optimizations based on the new architecture
>>
>> Key improvements:
>> - Centralized management of partition-related fields (partition_root_state,
>>    prs_err, nr_subparts, remote_sibling, effective_xcpus) within the
>>    partition_enable/disable/update functions
>> - Consistent operation patterns for both local and remote partitions
>>    with type-specific validation checks
>> - Fixed bug where isolcpus remained in root partition after isolated
>>    partition transitioned to root
> 
> You are really active in restructuring the cpuset code. However, the next merge window for v6.18 is
> going to open later today or tomorrow. I will start reviewing this patch series once the merge
> window closes 2 weeks later.
> 

Hi Longman,

I noticed that v6.18-rc1 was tagged on October 12.
I’d really appreciate it if you could find some time to review this patch series when you’re available.

-- 
Best regards,
Ridong

On 2025/9/29 0:00, Waiman Long wrote:
> On 9/28/25 3:12 AM, Chen Ridong wrote:
>> From: Chen Ridong <chenridong@huawei.com>
>>
>> The current local partition implementation consolidates all operations
>> (enable, disable, invalidate, and update) within the large
>> update_parent_effective_cpumask() function, which exceeds 300 lines.
>> This monolithic approach has become increasingly difficult to understand
>> and maintain. Additionally, partition-related fields are updated in
>> multiple locations, leading to redundant code and potential corner case
>> oversights.
>>
>> This patch series refactors the local partition logic by separating
>> operations into dedicated functions: local_partition_enable(),
>> local_partition_disable(), and local_partition_update(), creating
>> symmetry with the existing remote partition infrastructure.
>>
>> The series is organized as follows:
>>
>> 1. Infrastructure Preparation (Patches 1-2):
>>     - Code cleanup and preparation for the refactoring work
>>
>> 2. Core Partition Operations (Patches 3-5):
>>     - Factor out partition_enable(), partition_disable(), and
>>       partition_update() functions from remote partition operations
>>
>> 3. Local Partition Implementation (Patches 6-9):
>>     - Separate update_parent_effective_cpumask() into dedicated functions:
>>       * local_partition_enable()
>>       * local_partition_disable()
>>       * local_partition_invalidate()
>>       * local_partition_update()
>>
>> 4. Optimization and Cleanup (Patches 10-16):
>>     - Remove redundant partition-related operations
>>     - Additional optimizations based on the new architecture
>>
>> Key improvements:
>> - Centralized management of partition-related fields (partition_root_state,
>>    prs_err, nr_subparts, remote_sibling, effective_xcpus) within the
>>    partition_enable/disable/update functions
>> - Consistent operation patterns for both local and remote partitions
>>    with type-specific validation checks
>> - Fixed bug where isolcpus remained in root partition after isolated
>>    partition transitioned to root
> 
> You are really active in restructuring the cpuset code. However, the next merge window for v6.18 is
> going to open later today or tomorrow. I will start reviewing this patch series once the merge
> window closes 2 weeks later.
> 
> Cheers,
> Longman
> 

Thank you for letting me know about your schedule.

I've been quite active in the cgroup, especially with cpuset, I believe. :)

I've been thinking about reworking this series for some time, and I finally got it done.
Looking forward to your review.

-- 
Best regards,
Ridong