linux-kernel - Re: [PATCH -next RFC 00/16] cpuset: rework local partition logic

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2ccc217a-09f5-483a-bb91-4d0a25d98434@huaweicloud.com>
Date: Sun, 28 Sep 2025 17:57:27 +0800
From: Chen Ridong <chenridong@...weicloud.com>
To: longman@...hat.com, tj@...nel.org, hannes@...xchg.org, mkoutny@...e.com
Cc: linux-kernel@...r.kernel.org, lujialin4@...wei.com,
 chenridong@...wei.com,
 "open list:CONTROL GROUP (CGROUP)" <cgroups@...r.kernel.org>
Subject: Re: [PATCH -next RFC 00/16] cpuset: rework local partition logic


On 2025/9/28 15:12, Chen Ridong wrote:
> From: Chen Ridong <chenridong@...wei.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@...r.kernel.org

-- 
Best regards,
Ridong