mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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


  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®