Linux Kernel Selftest development
 help / color / mirror / Atom feed
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


  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