Re: [PATCH RFC v2 00/22] cpuset: rework local partition logic

[Chen Ridong]

On 2025/11/12 12:19, Waiman Long wrote:
> 
> On 11/11/25 11:11 PM, Chen Ridong wrote:
>>
>> On 2025/11/3 19:18, Chen Ridong wrote:
>>>
>>> On 2025/10/25 14:48, Chen Ridong wrote:
>>>> From: Chen Ridong <chenridong@xxxxxxxxxx>
>>>>
>>>> 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. Fix a bug that isolcpus stat in root partition.
>>>>
>>>> 2. Infrastructure Preparation (Patches 2-3):
>>>>     - Code cleanup and preparation for the refactoring work
>>>>
>>>> 3. Introduce partition operation helpers (Patches 4-6):
>>>>     - Intoduce out partition_enable(), partition_disable(), and
>>>>       partition_update() functions.
>>>>
>>>> 4. Use new helpers for remote partition (Patches 7-9)
>>>>
>>>> 5. Local Partition Implementation (Patches 10-13):
>>>>     - Separate update_parent_effective_cpumask() into dedicated functions:
>>>>       * local_partition_enable()
>>>>       * local_partition_disable()
>>>>       * local_partition_invalidate()
>>>>       * local_partition_update()
>>>>
>>>> 6. Optimization and Cleanup (Patches 14-22):
>>>>     - Remove redundant partition-related operations
>>>>     - Additional optimizations based on the new architecture
>>>>
>>>> ---
>>>>
>>>> Changes in v2:
>>>> - Added bugfix for root partition isolcpus at series start.
>>>> - Completed helper function implementations when first introduced.
>>>> - Split larger patches into smaller, more reviewable units.
>>>> - Incorporated feedback from Longman.
>>>>
>>>> Chen Ridong (22):
>>>>    cpuset: fix isolcpus stay in root when isolated partition changes to
>>>>      root
>>>>    cpuset: add early empty cpumask check in partition_xcpus_add/del
>>>>    cpuset: generalize validate_partition() interface
>>>>    cpuset: introduce partition_enable()
>>>>    cpuset: introduce partition_disable()
>>>>    cpuset: introduce partition_update()
>>>>    cpuset: use partition_enable() for remote partition enablement
>>>>    cpuset: use partition_disable() for remote partition disablement
>>>>    cpuset: use partition_update() for remote partition update
>>>>    cpuset: introduce local_partition_enable()
>>>>    cpuset: introduce local_partition_disable()
>>>>    cpuset: introduce local_partition_invalidate()
>>>>    cpuset: introduce local_partition_update()
>>>>    cpuset: remove update_parent_effective_cpumask
>>>>    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: use validate_local_partition in local_partition_enable
>>>>    cpuset: introduce validate_remote_partition
>>>>    cpuset: simplify update_prstate() function
>>>>    cpuset: remove prs_err clear when notify_partition_change
>>>>
>>>>   kernel/cgroup/cpuset.c | 1000 +++++++++++++++++++---------------------
>>>>   1 file changed, 463 insertions(+), 537 deletions(-)
>>>>
>>> Hi Longman,
>>>
>>> I'd appreciate it if you could have a look at this series when you have a moment.
>>>
>> Hi Longman,
>>
>> Could you kindly take a look at this series when you have a moment?
>> I'd appreciate any feedback you might have, and I’ll update the series accordingly.
> 
> I will take a look at this series tomorrow, though it has to be updated again anyway.
> 
> Cheers,
> Longman
> 
>>
> 

Thank you very much.

-- 
Best regards,
Ridong