From: Waiman Long <llong@redhat.com>
To: "Chen Ridong" <chenridong@huaweicloud.com>,
"Tejun Heo" <tj@kernel.org>,
"Johannes Weiner" <hannes@cmpxchg.org>,
"Michal Koutný" <mkoutny@suse.com>,
"Shuah Khan" <shuah@kernel.org>
Cc: linux-kernel@vger.kernel.org, cgroups@vger.kernel.org,
linux-kselftest@vger.kernel.org,
Sun Shaojie <sunshaojie@kylinos.cn>
Subject: Re: [cgroup/for-6.20 PATCH 1/4] cgroup/cpuset: Streamline rm_siblings_excl_cpus()
Date: Sat, 27 Dec 2025 02:40:53 -0500 [thread overview]
Message-ID: <2988a9d5-fe25-4668-93e3-8335360fcbec@redhat.com> (raw)
In-Reply-To: <c75025d3-17cd-47bb-a222-bde3a156bbbb@huaweicloud.com>
On 12/25/25 4:27 AM, Chen Ridong wrote:
>
> On 2025/12/25 15:30, Waiman Long wrote:
>> If exclusive_cpus is set, effective_xcpus must be a subset of
>> exclusive_cpus. Currently, rm_siblings_excl_cpus() checks both
>> exclusive_cpus and effective_xcpus connectively. It is simpler
>> to check only exclusive_cpus if non-empty or just effective_xcpus
>> otherwise.
>>
>> No functional change is expected.
>>
>> Signed-off-by: Waiman Long <longman@redhat.com>
>> ---
>> kernel/cgroup/cpuset.c | 17 +++++++++--------
>> 1 file changed, 9 insertions(+), 8 deletions(-)
>>
>> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
>> index 221da921b4f9..3d2d28f0fd03 100644
>> --- a/kernel/cgroup/cpuset.c
>> +++ b/kernel/cgroup/cpuset.c
>> @@ -1355,23 +1355,24 @@ static int rm_siblings_excl_cpus(struct cpuset *parent, struct cpuset *cs,
>> int retval = 0;
>>
>> if (cpumask_empty(excpus))
>> - return retval;
>> + return 0;
>>
>> /*
>> * Exclude exclusive CPUs from siblings
>> */
>> rcu_read_lock();
>> cpuset_for_each_child(sibling, css, parent) {
>> + struct cpumask *sibling_xcpus;
>> +
>> if (sibling == cs)
>> continue;
>>
>> - if (cpumask_intersects(excpus, sibling->exclusive_cpus)) {
>> - cpumask_andnot(excpus, excpus, sibling->exclusive_cpus);
>> - retval++;
>> - continue;
>> - }
>> - if (cpumask_intersects(excpus, sibling->effective_xcpus)) {
>> - cpumask_andnot(excpus, excpus, sibling->effective_xcpus);
>> + sibling_xcpus = cpumask_empty(sibling->exclusive_cpus)
>> + ? sibling->effective_xcpus
>> + : sibling->exclusive_cpus;
>> +
> I'm wondering if this is sufficient?
>
> sibling_xcpus = sibling->effective_xcpus
>
> p(exclusive_cpus = 1)
> / \
> a b(root, exclusive_cpus=1-7, effective_xcpus=1)
>
> What the sibling's effective exclusive CPUs actually should be is not CPUs 1-7 but CPU 1. So, do we
> need to remove CPUs 2-7?
By definition, exclusive_cpus have to be exclusive within the same child
cpuset level even if some of the CPUs cannot be granted from the parent.
So other siblings cannot use any of the CPUs 1-7 in its exclusive_cpus
list or the writing will fail. In the case of cpuset.cpus defined
partitions, those CPUs will be removed from its effective_xcpus list.
Cheers,
Longman
next prev parent reply other threads:[~2025-12-27 7:40 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-25 7:30 [cgroup/for-6.20 PATCH 0/4] cgroup/cpuset: Don't invalidate sibling partitions on cpuset.cpus conflict Waiman Long
2025-12-25 7:30 ` [cgroup/for-6.20 PATCH 1/4] cgroup/cpuset: Streamline rm_siblings_excl_cpus() Waiman Long
2025-12-25 9:27 ` Chen Ridong
2025-12-27 7:40 ` Waiman Long [this message]
2025-12-27 10:14 ` Chen Ridong
2025-12-25 7:30 ` [cgroup/for-6.20 PATCH 2/4] cgroup/cpuset: Consistently compute effective_xcpus in update_cpumasks_hier() Waiman Long
2025-12-27 10:10 ` Chen Ridong
2025-12-25 7:30 ` [cgroup/for-6.20 PATCH 3/4] cgroup/cpuset: Don't fail cpuset.cpus change in v2 Waiman Long
2025-12-25 9:30 ` Chen Ridong
2025-12-27 7:42 ` Waiman Long
2025-12-25 11:54 ` Chen Ridong
2025-12-27 8:03 ` Waiman Long
2025-12-25 7:30 ` [cgroup/for-6.20 PATCH 4/4] cgroup/cpuset: Don't invalidate sibling partitions on cpuset.cpus conflict Waiman Long
2025-12-29 12:42 ` [cgroup/for-6.20 PATCH 0/4] " Sun Shaojie
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=2988a9d5-fe25-4668-93e3-8335360fcbec@redhat.com \
--to=llong@redhat.com \
--cc=cgroups@vger.kernel.org \
--cc=chenridong@huaweicloud.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=mkoutny@suse.com \
--cc=shuah@kernel.org \
--cc=sunshaojie@kylinos.cn \
--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