Linux Kernel Selftest development
 help / color / mirror / Atom feed
From: Waiman Long <llong@redhat.com>
To: Sun Shaojie <sunshaojie@kylinos.cn>,
	llong@redhat.com, chenridong@huaweicloud.com, mkoutny@suse.com
Cc: cgroups@vger.kernel.org, hannes@cmpxchg.org,
	linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
	shuah@kernel.org, tj@kernel.org
Subject: Re: [PATCH v5] cpuset: Avoid invalidating sibling partitions on cpuset.cpus conflict.
Date: Mon, 24 Nov 2025 17:30:47 -0500	[thread overview]
Message-ID: <cae7a3ef-9808-47ac-a061-ab40d3c61020@redhat.com> (raw)
In-Reply-To: <20251119105749.1385946-1-sunshaojie@kylinos.cn>

On 11/19/25 5:57 AM, Sun Shaojie wrote:
> Currently, when setting a cpuset's cpuset.cpus to a value that conflicts
> with its sibling partition, the sibling's partition state becomes invalid.
> However, this invalidation is often unnecessary. If the cpuset being
> modified is exclusive, it should invalidate itself upon conflict.
>
> This patch applies only to the following two cases:
>
> Assume the machine has 4 CPUs (0-3).
>
>     root cgroup
>        /    \
>      A1      B1
>
> Case 1: A1 is exclusive, B1 is non-exclusive, set B1's cpuset.cpus
>
>   Table 1.1: Before applying this patch
>   Step                                       | A1's prstate | B1's prstate |
>   #1> echo "0-1" > A1/cpuset.cpus            | member       | member       |
>   #2> echo "root" > A1/cpuset.cpus.partition | root         | member       |
>   #3> echo "0" > B1/cpuset.cpus              | root invalid | member       |
>
> After step #3, A1 changes from "root" to "root invalid" because its CPUs
> (0-1) overlap with those requested by B1 (0). However, B1 can actually
> use CPUs 2-3(from B1's parent), so it would be more reasonable for A1 to
> remain as "root."
>
>   Table 1.2: After applying this patch
>   Step                                       | A1's prstate | B1's prstate |
>   #1> echo "0-1" > A1/cpuset.cpus            | member       | member       |
>   #2> echo "root" > A1/cpuset.cpus.partition | root         | member       |
>   #3> echo "0" > B1/cpuset.cpus              | root         | member       |
>
> Case 2: Both A1 and B1 are exclusive, set B1's cpuset.cpus
>
>   Table 2.1: Before applying this patch
>   Step                                       | A1's prstate | B1's prstate |
>   #1> echo "0-1" > A1/cpuset.cpus            | member       | member       |
>   #2> echo "root" > A1/cpuset.cpus.partition | root         | member       |
>   #3> echo "2" > B1/cpuset.cpus              | root         | member       |
>   #4> echo "root" > B1/cpuset.cpus.partition | root         | root         |
>   #5> echo "1-2" > B1/cpuset.cpus            | root invalid | root invalid |
>
> After step #4, B1 can exclusively use CPU 2. Therefore, at step #5,
> regardless of what conflicting value B1 writes to cpuset.cpus, it will
> always have at least CPU 2 available. This makes it unnecessary to mark
> A1 as "root invalid".
>
>   Table 2.2: After applying this patch
>   Step                                       | A1's prstate | B1's prstate |
>   #1> echo "0-1" > A1/cpuset.cpus            | member       | member       |
>   #2> echo "root" > A1/cpuset.cpus.partition | root         | member       |
>   #3> echo "2" > B1/cpuset.cpus              | root         | member       |
>   #4> echo "root" > B1/cpuset.cpus.partition | root         | root         |
>   #5> echo "1-2" > B1/cpuset.cpus            | root         | root invalid |
>
> In summary, regardless of how B1 configures its cpuset.cpus, there will
> always be available CPUs in B1's cpuset.cpus.effective. Therefore, there
> is no need to change A1 from "root" to "root invalid".
>
> All other cases remain unaffected. For example, cgroup-v1.

This patch is relatively simple. As others have pointed out, there are 
inconsistency depending on the operation ordering.

In the example above, the final configuration is A1:0-1 & B1:1-2. As the 
cpu lists overlap, we can't have both of them as valid partition roots. 
So either one of A1 or B1 is valid or they are both invalid. The current 
code makes them both invalid no matter the operation ordering.  This 
patch will make one of them valid given the operation ordering above. To 
minimize partition invalidation, we will have to live with the fact that 
it will be first-come first-serve as noted by Michal. I am not against 
this, we just have to document it. However, the following operation 
order will still make both of them invalid:

# echo "0-1" >A1/cpuset.cpus # echo "2" > B1/cpuset.cpus # echo "1-2" > 
B1/cpuset.cpus # echo "root" > A1/cpuset.cpus.partition # echo "root" > 
B1/cpuset.cpus.partition

To follow the "first-come first-serve" rule, A1 should be valid and B1 
invalid. That is the inconsistency with your current patch. To fix that, 
we still need to relax the overlap checking rule similar to your v4 patch.

Cheers,
Longman


  parent reply	other threads:[~2025-11-24 22:30 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-17  1:57 [PATCH v3 0/1] cpuset: relax the overlap check for cgroup-v2 Sun Shaojie
2025-11-17  1:57 ` [PATCH v4 1/1] " Sun Shaojie
2025-11-17  7:45   ` Chen Ridong
2025-11-17 10:00     ` Sun Shaojie
2025-11-17 11:37       ` Chen Ridong
2025-11-19 10:57         ` [PATCH v5] cpuset: Avoid invalidating sibling partitions on cpuset.cpus conflict Sun Shaojie
2025-11-19 13:20           ` Michal Koutný
2025-11-20  0:57             ` Chen Ridong
2025-11-20 13:07               ` Sun Shaojie
2025-11-20 13:25                 ` Chen Ridong
2025-11-21 10:33                   ` Sun Shaojie
2025-11-22  1:19                     ` Chen Ridong
2025-11-24 10:21                       ` Sun Shaojie
2025-11-20 13:05             ` Sun Shaojie
2025-11-26 14:13               ` Michal Koutný
2025-11-27  1:57                 ` Chen Ridong
2025-12-01  9:42                 ` Sun Shaojie
2025-11-20  0:51           ` Chen Ridong
2025-11-20 13:07             ` Sun Shaojie
2025-11-20 13:45               ` Chen Ridong
2025-11-21 10:32                 ` Sun Shaojie
2025-11-22  1:33                   ` Chen Ridong
2025-11-24 10:20                     ` Sun Shaojie
2025-11-24 11:33                       ` Chen Ridong
2025-11-26 12:29                         ` Sun Shaojie
2025-11-24 22:30           ` Waiman Long [this message]
2025-11-26 12:31             ` Sun Shaojie
2025-11-26 14:13             ` Michal Koutný
2025-11-26 19:43               ` Waiman Long
2025-11-27  1:55                 ` Chen Ridong
2025-12-01  9:44                   ` Sun Shaojie
2025-12-08 14:31                     ` Michal Koutný
2025-12-10 10:11                       ` Sun Shaojie
2025-12-11 10:59                         ` Michal Koutný
2025-12-12 10:10                           ` Sun Shaojie
2025-12-13  0:52                     ` Chen Ridong
2025-12-17  9:09                       ` Sun Shaojie
2025-12-08 14:32                 ` Michal Koutný
2025-12-13  4:58                   ` Waiman Long
2025-12-01  9:38             ` [PATCH v6] " Sun Shaojie
2025-12-17  9:45               ` [PING][PATCH " Sun Shaojie
2025-12-23  6:06                 ` Waiman Long
2025-12-22 15:26               ` [PATCH " Michal Koutný
2025-12-23  6:03                 ` Waiman Long
2025-12-25  7:30               ` Waiman Long
2025-11-19 11:03         ` [PATCH v4 1/1] cpuset: relax the overlap check for cgroup-v2 Sun Shaojie
2025-11-18 17:52   ` Michal Koutný
2025-11-19 11:04     ` Sun Shaojie
2025-11-18 19:53   ` Waiman Long
2025-11-19 11:05     ` Sun Shaojie
2025-11-17  3:23 ` [PATCH v3 0/1] " Chen Ridong
2025-11-17  5:58   ` 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=cae7a3ef-9808-47ac-a061-ab40d3c61020@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