From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1FA90315772 for ; Mon, 5 Jan 2026 04:34:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767587649; cv=none; b=e1zDu39nt+DGrB4YZVPuIH1ncwG5CkqhPduPFoDGvgEt4TqsKUGzZmfWAnl2GhASKopWvYPhf1+ELw3GhNety/SeFY7bAawGU5CnWwTOBye9yhdVZJVmurFzhZ5E+lWzCYkYkqS7lOA3OE3Xob8l4fOS4ZuYxsxWVXexOZ/f+6U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767587649; c=relaxed/simple; bh=3T+/lZggk41ZmUSEFDvnQxirFhUhk6Siu7jiOBQHW2Y=; h=From:Message-ID:Date:MIME-Version:Subject:To:Cc:References: In-Reply-To:Content-Type; b=FJTwKA1cMu4TkV4zJlHfjWVGQ9YvFvFBOuj3h1jxb/DBqzH6v8CFjYnO8EDQP9jQvldVjOa1pX5w+YqdcTEcRxWTUoq0qOVeolV5wi50xFnwAnyT7LntFvMcod/e8XMuFqeFLY4g1kjxh5naP090CjlHv8NG8gxUxQTlpwSulYA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=BWK/ly1H; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=gTIBGjVo; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="BWK/ly1H"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="gTIBGjVo" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1767587639; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=EsXkG064xWImXuIpJmll/7yvRdGEkNLFfXmtwpzJncw=; b=BWK/ly1HfNsiyTFr6GLv6mScSOhJdgKdd1oQtCBmJquuQ14wtmwbrzseCYx2ZURtw6PbRp e1f0uZ4kxnlyISVztiIrDVz8BhRXT1yKO7DlyHfHyQx02FMU6YR5YE0AqAE8pExNt2Humx 3N/6PEt6aUHAP10AoeJsS2osjO/TYLY= Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-500-4gq2b-ZlMG2BffKCBKqpUg-1; Sun, 04 Jan 2026 23:33:58 -0500 X-MC-Unique: 4gq2b-ZlMG2BffKCBKqpUg-1 X-Mimecast-MFC-AGG-ID: 4gq2b-ZlMG2BffKCBKqpUg_1767587638 Received: by mail-qv1-f69.google.com with SMTP id 6a1803df08f44-880501dcc67so581924646d6.3 for ; Sun, 04 Jan 2026 20:33:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1767587638; x=1768192438; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:user-agent:mime-version:date:message-id:from:from:to :cc:subject:date:message-id:reply-to; bh=EsXkG064xWImXuIpJmll/7yvRdGEkNLFfXmtwpzJncw=; b=gTIBGjVoEUlb8GDTnQYnLQR0f11uOglTwBVuZmWJN1Fxv0xsv06Ej+n+dByOBOxE0Y D99hGzIEU3zxd/Pqm0Gyhg7QeIPlQUGUZJ2jI8b0CYMaqlBTyFqQFQbGhtAWUwiKnVrw s1mbqBAiKbRGRA4DvpGw3wpPJUB+GO7G2oP6xJM5eqK7/5Z7oL3uY9SELSuFOKLp6qCR xaUhuZs4JsVwZMYTGN6DvoyxYkFMP6aRcj1e8Rl1ez3ilE3oeOhsIw11IpsB+dMdx8UY 49BErWOoKeGnYmkkgqXw8fZa3Dp+rCIos0UtvHkfQA8L36ASXVab4TsZmyM5ro050mUM Mwzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767587638; x=1768192438; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:user-agent:mime-version:date:message-id:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=EsXkG064xWImXuIpJmll/7yvRdGEkNLFfXmtwpzJncw=; b=VTUl6aJLZDCk0M5PJb56vSxSwEt2jb/QxMwEgMl9X3/etQOHwdqDIS5TkX4enmJYrU mCL5mVzSgW/SXLTIowcimD5DxkjxzNLavVBGBLSj0ZCTPC7coiWsz+qGxfFo1lQQxu3A MQW6wCzLP9L18xVttPABTto0k/7i+3bRmzfAYHlqaCywNBkSm5+CP6YxzRBPQ4dSdo5m 6tTye0JPYoyusiGDAkeHufYoiD0i4QXXZkvXSR1jpdpxuOTbqKA9c0m1pFMEm8RBHAwT IfMCW3ZZpErOAt58914IxYlgFG5mRImOEi+Esf6zsShE2+25wkpUWSUf16jw13bV/kQ/ jvIA== X-Forwarded-Encrypted: i=1; AJvYcCVHLx1Y9keLo7bGPUVovaWhZp/c4N1fKgmr2PRn4AO8l40K41Y2bcEyiXeyCWxoTtUW835h1vK3tOji40Q=@vger.kernel.org X-Gm-Message-State: AOJu0YwEbsyvZQYhtS++fULBPEH0v9jw59rAdD6twDDoSYRt8+Sks+5s nPqMZUK/cyVp6fPqwlLWwElbhmuex0aiAsC3m9ylfLooExSI5aSHG7MpbUrDPYP43slyugIOXc9 NJbc2cQO/zZKO/LGnWAvSawVIQqIH2LrqFPj+Le75khGwKms9E1991RAOsW/7/krkkg== X-Gm-Gg: AY/fxX533LkDC0GAWcOZkeqHDfTCw3B5TaseOy+J6oqWMB+05TGBmLS/57TOMi6gZqW 8FfDZTxUTTWyEO8c9J+YwBGKK5+d2w9FSnxswAn6paRDd2fTw1mlrdmp3setoB87l3oE7S/ZBSx kmeLaPavSqZkE74L+sBb6vIzUw1p9Wr8sMmUgUdIohsQ1snIR/1Z2SEjEvPza226rDHzXGWZSlb sZgZVoO1naGhobd/NJuFN8qgIdQO17ahCicnExyq8RQ0zBj9vS7lyMJOIPPh7/GySl29Jk2CAry ZwQGhELQJ1nroQtNQGCGnYUm/l77u5nguQuBufUkuz0LNbO2kIFGuanCoouOiMSCga+vXfgXd43 0N0WnWdxqXWqIHqthbWTvj3Ey3JECvUB69xN38MJzzcWvnEnhJ+L5f1ni X-Received: by 2002:ad4:5b8a:0:b0:880:5a05:925f with SMTP id 6a1803df08f44-88d851fd7f5mr880375266d6.13.1767587638100; Sun, 04 Jan 2026 20:33:58 -0800 (PST) X-Google-Smtp-Source: AGHT+IE6DcRe9C6u3k7gb2s0ee5NzGtfc03MoZnKJsOHm3lHdWNWpkBMcV5gluaDDwHAB/FLg7kV9Q== X-Received: by 2002:ad4:5b8a:0:b0:880:5a05:925f with SMTP id 6a1803df08f44-88d851fd7f5mr880375106d6.13.1767587637713; Sun, 04 Jan 2026 20:33:57 -0800 (PST) Received: from ?IPV6:2601:188:c102:b180:1f8b:71d0:77b1:1f6e? ([2601:188:c102:b180:1f8b:71d0:77b1:1f6e]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-88d997ada77sm341759336d6.37.2026.01.04.20.33.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 04 Jan 2026 20:33:57 -0800 (PST) From: Waiman Long X-Google-Original-From: Waiman Long Message-ID: <13975af6-97af-49d8-ae85-d126a65715ee@redhat.com> Date: Sun, 4 Jan 2026 23:33:56 -0500 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH RESEND -next 00/21] cpuset: rework local partition logic To: Chen Ridong , tj@kernel.org, hannes@cmpxchg.org, mkoutny@suse.com Cc: cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, lujialin4@huawei.com References: <20251225123058.231765-1-chenridong@huaweicloud.com> <7937ad21-8c98-4bd8-8a5d-93f868bcb8b5@huaweicloud.com> Content-Language: en-US In-Reply-To: <7937ad21-8c98-4bd8-8a5d-93f868bcb8b5@huaweicloud.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/4/26 11:01 PM, Chen Ridong wrote: > > On 2025/12/25 20:30, Chen Ridong wrote: >> From: Chen Ridong >> >> 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. Introduce partition operation helpers (Patches 3-5): >> - Introduce out partition_enable(), partition_disable(), and >> partition_update() functions. >> >> 3. Use new helpers for remote partition (Patches 6-8) >> >> 4. Local Partition Implementation (Patches 9-12): >> - Separate update_parent_effective_cpumask() into dedicated functions: >> * local_partition_enable() >> * local_partition_disable() >> * local_partition_update() >> >> 5. Optimization and Cleanup (Patches 13-21): >> - Remove redundant partition-related operations >> - Additional optimizations based on the new architecture >> >> base-commit: cc3aa43b44bdb43dfbac0fcb51c56594a11338a8 >> >> --- >> >> Changes in RESEND: >> 1. Rebase on the next-20251219 >> >> Changes from RFC v2: >> 1. Dropped the bugfix (already merged/fixed upstream) >> 2. Rebased onto next >> 3. Introduced partition_switch to handle root state switches >> 4. Directly use local_partition_disable()—no longer first introduce >> local_partition_invalidate() before unifying the two >> 5. Incorporated modifications based on Longman's suggestions >> >> Changes in RFC v1: >> 1. Added bugfix for root partition isolcpus at series start. >> 2. Completed helper function implementations when first introduced. >> 3. Split larger patches into smaller, more reviewable units. >> 4. Incorporated feedback from Longman. >> >> Chen Ridong (21): >> cpuset: add early empty cpumask check in partition_xcpus_add/del >> cpuset: generalize the 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: user local_partition_disable() to invalidate local partition >> 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: use partition_disable for compute_partition_effective_cpumask >> cpuset: use validate_local_partition in local_partition_enable >> cpuset: introduce validate_remote_partition >> cpuset: simplify the update_prstate() function >> cpuset: remove prs_err clear when notify_partition_change >> cpuset: Remove unnecessary validation in partition_cpus_change >> >> kernel/cgroup/cpuset.c | 1023 ++++++++++++++++++---------------------- >> 1 file changed, 454 insertions(+), 569 deletions(-) >> > Hi Longman, > > This series has been out for a while. I'd appreciate it if you could take some time to review it. > Sorry for being late in reviewing this updated series. However, there are also other cpuset related patch series that are being reviewed at the moment. Since this is mainly a cleanup patch making the code easier to understand, but it does a major restructuring of the existing code which will likely make the other patches harder to merge. So I would like to prioritize the other fix and feature patches first. I will try to review the patches when I have time, but I want this series to be merged after other cpuset patches are done. Sorry for the inconvenience caused as you may have to redo the patch series again when the code base is settled down. Cheers, Longman