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: cgroups@vger.kernel.org, linux-kernel@vger.kernel.org,
lujialin4@huawei.com, chenridong@huawei.com
Subject: Re: [PATCH RFC v2 10/22] cpuset: introduce local_partition_enable()
Date: Wed, 12 Nov 2025 21:58:08 -0500 [thread overview]
Message-ID: <8bb19728-8611-4266-aa8e-6dd4783c4702@redhat.com> (raw)
In-Reply-To: <47c20c78-9f7f-4134-8835-3c4f5bff4c30@huaweicloud.com>
On 11/12/25 9:49 PM, Chen Ridong wrote:
>
> On 2025/11/13 5:47, Waiman Long wrote:
>> On 10/25/25 2:48 AM, Chen Ridong wrote:
>>> From: Chen Ridong <chenridong@huawei.com>
>>>
>>> The partition_enable() function introduced in the previous patch can be
>>> reused to enable local partitions.
>>>
>>> The local_partition_enable() function is introduced, which factors out the
>>> local partition enablement logic from update_parent_effective_cpumask().
>>> After passing local partition validation checks, it delegates to
>>> partition_enable() to complete the partition setup.
>>>
>>> This refactoring creates a clear separation between local and remote
>>> partition operations while maintaining code reuse through the shared
>>> partition_enable() infrastructure.
>>>
>>> Signed-off-by: Chen Ridong <chenridong@huawei.com>
>>> ---
>>> kernel/cgroup/cpuset.c | 94 ++++++++++++++++++++++++++----------------
>>> 1 file changed, 59 insertions(+), 35 deletions(-)
>>>
>>> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
>>> index 5b57c5370641..b308d9f80eef 100644
>>> --- a/kernel/cgroup/cpuset.c
>>> +++ b/kernel/cgroup/cpuset.c
>>> @@ -1822,6 +1822,61 @@ static void remote_cpus_update(struct cpuset *cs, struct cpumask *xcpus,
>>> remote_partition_disable(cs, tmp);
>>> }
>>> +/**
>>> + * local_partition_enable - Enable local partition for a cpuset
>>> + * @cs: Target cpuset to become a local partition root
>>> + * @new_prs: New partition root state to apply
>>> + * @tmp: Temporary masks for CPU calculations
>>> + *
>>> + * This function enables local partition root capability for a cpuset by
>>> + * validating prerequisites, computing exclusive CPUs, and updating the
>>> + * partition hierarchy.
>>> + *
>>> + * Return: 0 on success, error code on failure
>>> + */
>>> +static int local_partition_enable(struct cpuset *cs,
>>> + int new_prs, struct tmpmasks *tmp)
>>> +{
>>> + struct cpuset *parent = parent_cs(cs);
>>> + enum prs_errcode part_error;
>>> + bool cpumask_updated = false;
>>> +
>>> + lockdep_assert_held(&cpuset_mutex);
>>> + WARN_ON_ONCE(is_remote_partition(cs)); /* For local partition only */
>>> +
>>> + /*
>>> + * The parent must be a partition root.
>>> + * The new cpumask, if present, or the current cpus_allowed must
>>> + * not be empty.
>>> + */
>>> + if (!is_partition_valid(parent)) {
>>> + return is_partition_invalid(parent)
>>> + ? PERR_INVPARENT : PERR_NOTPART;
>>> + }
>>> +
>>> + /*
>>> + * Need to call compute_excpus() in case
>>> + * exclusive_cpus not set. Sibling conflict should only happen
>>> + * if exclusive_cpus isn't set.
>>> + */
>>> + if (compute_excpus(cs, tmp->new_cpus))
>>> + WARN_ON_ONCE(!cpumask_empty(cs->exclusive_cpus));
>>> +
>>> + part_error = validate_partition(cs, new_prs, tmp->new_cpus);
>>> + if (part_error)
>>> + return part_error;
>>> +
>>> + cpumask_updated = cpumask_andnot(tmp->addmask, tmp->new_cpus,
>>> + parent->effective_cpus);
>> What is the purpose of this cpumask_andnot() operation? Is it just to create the cpumask_updated
>> boolean? At this point, cpumask_updated should always be true. If not, we have to add validation
>> check to return an error.
>>
>> Cheers,
>> Longman
>>
> I want to support switching the root partition’s state between "root" and "isolated"—for example, an
> isolated partition switching to root without changing its CPU mask.
>
> Adding a comment to clarify this behavior would be helpful.
For state switching, I would suggest to use a separate helper just for
state switching as such switching can be done to both local and remote
partition.
Cheers,
Longman
next prev parent reply other threads:[~2025-11-13 2:58 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-25 6:48 [PATCH RFC v2 00/22] cpuset: rework local partition logic Chen Ridong
2025-10-25 6:48 ` [PATCH RFC v2 01/22] cpuset: fix isolcpus stay in root when isolated partition changes to root Chen Ridong
2025-11-12 20:09 ` Waiman Long
2025-11-13 1:24 ` Chen Ridong
2025-10-25 6:48 ` [PATCH RFC v2 02/22] cpuset: add early empty cpumask check in partition_xcpus_add/del Chen Ridong
2025-11-12 20:18 ` Waiman Long
2025-11-13 1:36 ` Chen Ridong
2025-10-25 6:48 ` [PATCH RFC v2 03/22] cpuset: generalize validate_partition() interface Chen Ridong
2025-10-25 6:48 ` [PATCH RFC v2 04/22] cpuset: introduce partition_enable() Chen Ridong
2025-11-12 20:40 ` Waiman Long
2025-11-13 1:38 ` Chen Ridong
2025-10-25 6:48 ` [PATCH RFC v2 05/22] cpuset: introduce partition_disable() Chen Ridong
2025-10-25 6:48 ` [PATCH RFC v2 06/22] cpuset: introduce partition_update() Chen Ridong
2025-11-12 20:58 ` Waiman Long
2025-11-13 7:22 ` Chen Ridong
2025-10-25 6:48 ` [PATCH RFC v2 07/22] cpuset: use partition_enable() for remote partition enablement Chen Ridong
2025-10-25 6:48 ` [PATCH RFC v2 08/22] cpuset: use partition_disable() for remote partition disablement Chen Ridong
2025-10-25 6:48 ` [PATCH RFC v2 09/22] cpuset: use partition_update() for remote partition update Chen Ridong
2025-10-25 6:48 ` [PATCH RFC v2 10/22] cpuset: introduce local_partition_enable() Chen Ridong
2025-11-12 21:47 ` Waiman Long
2025-11-13 2:49 ` Chen Ridong
2025-11-13 2:58 ` Waiman Long [this message]
2025-11-13 7:16 ` Chen Ridong
2025-10-25 6:48 ` [PATCH RFC v2 11/22] cpuset: introduce local_partition_disable() Chen Ridong
2025-11-12 22:10 ` Waiman Long
2025-11-13 3:27 ` Chen Ridong
2025-10-25 6:48 ` [PATCH RFC v2 12/22] cpuset: introduce local_partition_invalidate() Chen Ridong
2025-11-12 22:54 ` Waiman Long
2025-11-13 7:03 ` Chen Ridong
2025-11-13 0:15 ` Waiman Long
2025-10-25 6:48 ` [PATCH RFC v2 13/22] cpuset: introduce local_partition_update() Chen Ridong
2025-11-13 2:06 ` Waiman Long
2025-11-13 6:33 ` Chen Ridong
2025-10-25 6:48 ` [PATCH RFC v2 14/22] cpuset: remove update_parent_effective_cpumask Chen Ridong
2025-10-25 6:48 ` [PATCH RFC v2 15/22] cpuset: remove redundant partition field updates Chen Ridong
2025-10-25 6:48 ` [PATCH RFC v2 16/22] cpuset: simplify partition update logic for hotplug tasks Chen Ridong
2025-10-25 6:48 ` [PATCH RFC v2 17/22] cpuset: unify local partition disable and invalidate Chen Ridong
2025-10-25 6:48 ` [PATCH RFC v2 18/22] cpuset: use partition_disable for compute_partition_effective_cpumask Chen Ridong
2025-10-25 6:48 ` [PATCH RFC v2 19/22] cpuset: use validate_local_partition in local_partition_enable Chen Ridong
2025-10-25 6:48 ` [PATCH RFC v2 20/22] cpuset: introduce validate_remote_partition Chen Ridong
2025-10-25 6:48 ` [PATCH RFC v2 21/22] cpuset: simplify update_prstate() function Chen Ridong
2025-10-25 6:48 ` [PATCH RFC v2 22/22] cpuset: remove prs_err clear when notify_partition_change Chen Ridong
2025-11-03 11:18 ` [PATCH RFC v2 00/22] cpuset: rework local partition logic Chen Ridong
2025-11-12 4:11 ` Chen Ridong
2025-11-12 4:19 ` Waiman Long
2025-11-12 4:49 ` 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=8bb19728-8611-4266-aa8e-6dd4783c4702@redhat.com \
--to=llong@redhat.com \
--cc=cgroups@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®