From: Waiman Long <llong@redhat.com>
To: Chen Ridong <chenridong@huaweicloud.com>,
Waiman Long <llong@redhat.com>,
tj@kernel.org, hannes@cmpxchg.org, mkoutny@suse.com
Cc: cgups@vger.kernel.org, linux-kernel@vger.kernel.org,
lujialin4@huawei.com, chenridong@huawei.com
Subject: Re: [PATCH -next RFC 03/16] cpuset: factor out partition_enable() function
Date: Mon, 20 Oct 2025 15:42:22 -0400 [thread overview]
Message-ID: <e8018984-96ed-49fa-8571-79a0d39cb218@redhat.com> (raw)
In-Reply-To: <fa7fa2e5-c602-4318-90e1-89c742c6cc1a@huaweicloud.com>
On 10/20/25 3:48 AM, Chen Ridong wrote:
>
> On 2025/10/20 10:39, Waiman Long wrote:
>> On 9/28/25 3:12 AM, Chen Ridong wrote:
>>> From: Chen Ridong <chenridong@huawei.com>
>>>
>>> Extract the core partition enablement logic into a dedicated
>>> partition_enable() function. This refactoring centralizes updates to key
>>> cpuset data structures including remote_sibling, effective_xcpus,
>>> partition_root_state, and prs_err.
>>>
>>> The function handles the complete partition enablement workflow:
>>> - Adding exclusive CPUs via partition_xcpus_add()
>>> - Managing remote sibling relationships
>>> - Synchronizing effective exclusive CPUs mask
>>> - Updating partition state and error status
>>> - Triggering required scheduler domain rebuilds
>>>
>>> This creates a coherent interface for partition operations and establishes
>>> a foundation for future local partition support while maintaining existing
>>> remote partition behavior.
>>>
>>> Signed-off-by: Chen Ridong <chenridong@huawei.com>
>>> ---
>>> kernel/cgroup/cpuset.c | 55 +++++++++++++++++++++++++++++++++---------
>>> 1 file changed, 44 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
>>> index 0787904321a9..43ce62f4959c 100644
>>> --- a/kernel/cgroup/cpuset.c
>>> +++ b/kernel/cgroup/cpuset.c
>>> @@ -1515,6 +1515,49 @@ static inline bool is_local_partition(struct cpuset *cs)
>>> return is_partition_valid(cs) && !is_remote_partition(cs);
>>> }
>>> +static void partition_state_update(struct cpuset *cs, int new_prs,
>>> + enum prs_errcode prs_err)
>>> +{
>>> + lockdep_assert_held(&callback_lock);
>>> +
>>> + cs->partition_root_state = new_prs;
>>> + WRITE_ONCE(cs->prs_err, prs_err);
>>> + if (!is_partition_valid(cs))
>>> + reset_partition_data(cs);
>>> +}
>>> +
>>> +/**
>>> + * partition_enable - Transitions a cpuset to a partition root
>>> + * @cs: The cpuset to enable partition for
>>> + * @parent: Parent cpuset of @cs, NULL for remote parent
>>> + * @new_prs: New partition root state to set
>>> + * @new_excpus: New exclusive CPUs mask for the partition
>>> + *
>>> + * Transitions a cpuset to a partition root, only for v2.
>>> + */
>>> +static void partition_enable(struct cpuset *cs, struct cpuset *parent,
>>> + int new_prs, struct cpumask *new_excpus)
>>> +{
>>> + bool isolcpus_updated;
>>> +
>>> + lockdep_assert_held(&cpuset_mutex);
>>> + WARN_ON_ONCE(new_prs <= 0);
>>> + WARN_ON_ONCE(!cpuset_v2());
>>> +
>>> + if (cs->partition_root_state == new_prs)
>>> + return;
>>> +
>>> + spin_lock_irq(&callback_lock);
>>> + /* enable partition should only add exclusive cpus */
>>> + isolcpus_updated = partition_xcpus_add(new_prs, parent, new_excpus);
>>> + list_add(&cs->remote_sibling, &remote_children);
>>> + cpumask_copy(cs->effective_xcpus, new_excpus);
>>> + partition_state_update(cs, new_prs, PERR_NONE);
>>> + spin_unlock_irq(&callback_lock);
>>> + update_unbound_workqueue_cpumask(isolcpus_updated);
>>> + cpuset_force_rebuild();
>>> +}
>>> +
>> partition_enable() is supposed to be a common helper used for the creation of both local and remote
>> partitions. The one in this patch does work for remote partition but not for local partition. I
>> would prefer to make it good for both cases when you introduce it instead adding code in patch 6 to
>> make it work for local partition later in the series. It will make it easier to review instead of
>> jumping back and forth to make sure that it will do the right thing.
>>
>> Cheers,
>> Longman
>>
> Thank you, Longman.
>
> My original intention was to keep the changes easier to review. Patches 3–5 are meant to be pure
> refactoring moves of code from the remote partition logic, without altering any behavior.
>
> Would it be clearer to proceed in the following stages:
>
> 1. Introduce partition_enable(), partition_disable(), and partition_update() with their complete
> logic first.
> 2. Replace the corresponding logic in remote partitions with these new helpers.
> 3. Then, replace the logic in local partitions with the same helpers.
>
Yes, that should make it easier to review.
Thanks,
Longman
next prev parent reply other threads:[~2025-10-20 19:42 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-28 7:12 [PATCH -next RFC 00/16] cpuset: rework local partition logic Chen Ridong
2025-09-28 7:12 ` [PATCH -next RFC 01/16] cpuset: use update_partition_sd_lb in update_cpumasks_hier Chen Ridong
2025-10-20 2:37 ` Waiman Long
2025-10-20 7:30 ` Chen Ridong
2025-09-28 7:12 ` [PATCH -next RFC 02/16] cpuset: generalize validate_partition() interface Chen Ridong
2025-09-28 7:12 ` [PATCH -next RFC 03/16] cpuset: factor out partition_enable() function Chen Ridong
2025-10-20 2:39 ` Waiman Long
2025-10-20 7:48 ` Chen Ridong
2025-10-20 19:42 ` Waiman Long [this message]
2025-10-21 0:52 ` Chen Ridong
2025-09-28 7:12 ` [PATCH -next RFC 04/16] cpuset: factor out partition_disable() function Chen Ridong
2025-09-28 7:12 ` [PATCH -next RFC 05/16] cpuset: factor out partition_update() function Chen Ridong
2025-10-20 2:43 ` Waiman Long
2025-10-20 8:05 ` Chen Ridong
2025-10-20 19:45 ` Waiman Long
2025-09-28 7:12 ` [PATCH -next RFC 06/16] cpuset: introduce local_partition_enable() Chen Ridong
2025-10-20 2:44 ` Waiman Long
2025-10-20 8:06 ` Chen Ridong
2025-09-28 7:12 ` [PATCH -next RFC 07/16] cpuset: introduce local_partition_disable() Chen Ridong
2025-10-20 2:46 ` Waiman Long
2025-10-20 8:06 ` Chen Ridong
2025-09-28 7:12 ` [PATCH -next RFC 08/16] cpuset: introduce local_partition_invalidate() Chen Ridong
2025-10-20 2:48 ` Waiman Long
2025-10-20 8:28 ` Chen Ridong
2025-09-28 7:12 ` [PATCH -next RFC 09/16] cpuset: introduce local_partition_update() Chen Ridong
2025-10-20 2:57 ` Waiman Long
2025-10-20 9:24 ` Chen Ridong
2025-09-28 7:13 ` [PATCH -next RFC 10/16] cpuset: remove redundant partition field updates Chen Ridong
2025-09-28 7:13 ` [PATCH -next RFC 11/16] cpuset: simplify partition update logic for hotplug tasks Chen Ridong
2025-10-20 3:00 ` Waiman Long
2025-10-20 8:44 ` Chen Ridong
2025-09-28 7:13 ` [PATCH -next RFC 12/16] cpuset: unify local partition disable and invalidate Chen Ridong
2025-09-28 7:13 ` [PATCH -next RFC 13/16] cpuset: use partition_disable for compute_partition_effective_cpumask Chen Ridong
2025-10-20 3:02 ` Waiman Long
2025-10-20 8:47 ` Chen Ridong
2025-09-28 7:13 ` [PATCH -next RFC 14/16] cpuset: fix isolcpus stay in root when isolated partition changes to root Chen Ridong
2025-10-20 3:06 ` Waiman Long
2025-10-20 9:13 ` Chen Ridong
2025-10-22 10:49 ` Chen Ridong
2025-09-28 7:13 ` [PATCH -next RFC 15/16] cpuset: use partition_disable for update_prstate Chen Ridong
2025-09-28 7:13 ` [PATCH -next RFC 16/16] cpuset: remove prs_err clear when notify_partition_change Chen Ridong
2025-09-28 9:57 ` [PATCH -next RFC 00/16] cpuset: rework local partition logic Chen Ridong
2025-09-28 16:00 ` Waiman Long
2025-09-29 1:17 ` Chen Ridong
2025-10-17 1:05 ` Chen Ridong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e8018984-96ed-49fa-8571-79a0d39cb218@redhat.com \
--to=llong@redhat.com \
--cc=cgups@vger.kernel.org \
--cc=chenridong@huawei.com \
--cc=chenridong@huaweicloud.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lujialin4@huawei.com \
--cc=mkoutny@suse.com \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®