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 for Android: free password hash cracker in your pocket

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

Message-ID: <9cdd5042-a592-4db3-a4bf-2ec126f1a169@huaweicloud.com>
Date: Fri, 17 Oct 2025 09:05:39 +0800
From: Chen Ridong <chenridong@...weicloud.com>
To: Waiman Long <llong@...hat.com>, tj@...nel.org, hannes@...xchg.org,
 mkoutny@...e.com
Cc: cgroups@...r.kernel.org, linux-kernel@...r.kernel.org,
 lujialin4@...wei.com, chenridong@...wei.com
Subject: Re: [PATCH -next RFC 00/16] cpuset: rework local partition logic



On 2025/9/29 0:00, Waiman Long wrote:
> On 9/28/25 3:12 AM, 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
> 
> 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