From: Waiman Long <llong@redhat.com>
To: Tejun Heo <tj@kernel.org>
Cc: Zefan Li <lizefan.x@bytedance.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Jonathan Corbet <corbet@lwn.net>, Shuah Khan <shuah@kernel.org>,
cgroups@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Roman Gushchin <guro@fb.com>, Phil Auld <pauld@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Juri Lelli <juri.lelli@redhat.com>
Subject: Re: [PATCH v2 2/6] cgroup/cpuset: Clarify the use of invalid partition root
Date: Mon, 28 Jun 2021 09:06:50 -0400 [thread overview]
Message-ID: <6ea1ac38-73e1-3f78-a5d2-a4c23bcd8dd1@redhat.com> (raw)
In-Reply-To: <YNcHOe3o//pIiByh@mtj.duckdns.org>
On 6/26/21 6:53 AM, Tejun Heo wrote:
> Hello, Waiman.
>
> On Mon, Jun 21, 2021 at 02:49:20PM -0400, Waiman Long wrote:
>> 1) A partition root can't be changed to member if it has child partition
>> roots.
>> 2) Removing CPUs from cpuset.cpus that causes it to become invalid is
>> not allowed.
> I'm not a fan of this approach. No matter what we have to be able to handle
> CPU removals which are user-iniated operations anyway, so I don't see why
> we're adding a different way of handling a different set of operations. Just
> handle them the same?
The main reason for doing this is because normal cpuset control file
actions are under the direct control of the cpuset code. So it is up to
us to decide whether to grant it or deny it. Hotplug, on the other hand,
is not under the control of cpuset code. It can't deny a hotplug
operation. This is the main reason why the partition root error state
was added in the first place.
Normally, users can set cpuset.cpus to whatever value they want even
though they are not actually granted. However, turning on partition root
is under more strict control. You can't turn on partition root if the
CPUs requested cannot actually be granted. The problem with setting the
state to just partition error is that users may not be aware that the
partition creation operation fails. We can't assume all users will do
the proper error checking. I would rather let them know the operation
fails rather than relying on them doing the proper check afterward.
Yes, I agree that it is a different philosophy than the original cpuset
code, but I thought one reason of doing cgroup v2 is to simplify the
interface and make it a bit more erorr-proof. Since partition root
creation is a relatively rare operation, we can afford to make it more
strict than the other operations.
Cheers,
Longman
WARNING: multiple messages have this Message-ID (diff)
From: Waiman Long <llong@redhat.com>
To: Tejun Heo <tj@kernel.org>
Cc: Zefan Li <lizefan.x@bytedance.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Jonathan Corbet <corbet@lwn.net>, Shuah Khan <shuah@kernel.org>,
cgroups@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Roman Gushchin <guro@fb.com>, Phil Auld <pauld@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Juri Lelli <juri.lelli@redhat.com>
Subject: Re: [PATCH v2 2/6] cgroup/cpuset: Clarify the use of invalid partition root
Date: Mon, 28 Jun 2021 09:06:50 -0400 [thread overview]
Message-ID: <6ea1ac38-73e1-3f78-a5d2-a4c23bcd8dd1@redhat.com> (raw)
In-Reply-To: <YNcHOe3o//pIiByh@mtj.duckdns.org>
On 6/26/21 6:53 AM, Tejun Heo wrote:
> Hello, Waiman.
>
> On Mon, Jun 21, 2021 at 02:49:20PM -0400, Waiman Long wrote:
>> 1) A partition root can't be changed to member if it has child partition
>> roots.
>> 2) Removing CPUs from cpuset.cpus that causes it to become invalid is
>> not allowed.
> I'm not a fan of this approach. No matter what we have to be able to handle
> CPU removals which are user-iniated operations anyway, so I don't see why
> we're adding a different way of handling a different set of operations. Just
> handle them the same?
The main reason for doing this is because normal cpuset control file
actions are under the direct control of the cpuset code. So it is up to
us to decide whether to grant it or deny it. Hotplug, on the other hand,
is not under the control of cpuset code. It can't deny a hotplug
operation. This is the main reason why the partition root error state
was added in the first place.
Normally, users can set cpuset.cpus to whatever value they want even
though they are not actually granted. However, turning on partition root
is under more strict control. You can't turn on partition root if the
CPUs requested cannot actually be granted. The problem with setting the
state to just partition error is that users may not be aware that the
partition creation operation fails. We can't assume all users will do
the proper error checking. I would rather let them know the operation
fails rather than relying on them doing the proper check afterward.
Yes, I agree that it is a different philosophy than the original cpuset
code, but I thought one reason of doing cgroup v2 is to simplify the
interface and make it a bit more erorr-proof. Since partition root
creation is a relatively rare operation, we can afford to make it more
strict than the other operations.
Cheers,
Longman
next prev parent reply other threads:[~2021-06-28 13:07 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-21 18:49 [PATCH v2 0/6] cgroup/cpuset: Add new cpuset partition type & empty effecitve cpus Waiman Long
2021-06-21 18:49 ` Waiman Long
2021-06-21 18:49 ` [PATCH v2 1/6] cgroup/cpuset: Miscellaneous code cleanup Waiman Long
2021-06-21 18:49 ` Waiman Long
2021-06-21 18:49 ` [PATCH v2 2/6] cgroup/cpuset: Clarify the use of invalid partition root Waiman Long
2021-06-26 10:53 ` Tejun Heo
2021-06-28 13:06 ` Waiman Long [this message]
2021-06-28 13:06 ` Waiman Long
2021-07-05 17:51 ` Tejun Heo
2021-07-16 18:44 ` Waiman Long
2021-07-16 18:44 ` Waiman Long
2021-07-16 18:59 ` Waiman Long
2021-07-16 18:59 ` Waiman Long
2021-07-16 20:08 ` Waiman Long
2021-07-16 20:08 ` Waiman Long
2021-07-16 20:46 ` Tejun Heo
2021-07-16 21:12 ` Waiman Long
2021-07-16 21:12 ` Waiman Long
2021-07-16 21:18 ` Tejun Heo
2021-07-16 21:18 ` Tejun Heo
2021-07-16 21:28 ` Waiman Long
2021-07-16 21:28 ` Waiman Long
2021-06-21 18:49 ` [PATCH v2 3/6] cgroup/cpuset: Add a new isolated cpus.partition type Waiman Long
2021-06-21 18:49 ` Waiman Long
2021-06-24 12:51 ` Michal Koutný
2021-06-24 12:51 ` Michal Koutný
2021-06-24 15:23 ` Waiman Long
2021-06-24 15:23 ` Waiman Long
2021-06-21 18:49 ` [PATCH v2 4/6] cgroup/cpuset: Allow non-top parent partition root to distribute out all CPUs Waiman Long
2021-06-21 18:49 ` Waiman Long
2021-06-21 18:49 ` [PATCH v2 5/6] cgroup/cpuset: Update description of cpuset.cpus.partition in cgroup-v2.rst Waiman Long
2021-06-21 18:49 ` Waiman Long
2021-06-21 18:49 ` [PATCH v2 6/6] kselftest/cgroup: Add cpuset v2 partition root state test Waiman Long
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=6ea1ac38-73e1-3f78-a5d2-a4c23bcd8dd1@redhat.com \
--to=llong@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=corbet@lwn.net \
--cc=guro@fb.com \
--cc=hannes@cmpxchg.org \
--cc=juri.lelli@redhat.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=lizefan.x@bytedance.com \
--cc=pauld@redhat.com \
--cc=peterz@infradead.org \
--cc=shuah@kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.