From: Tejun Heo <tj@kernel.org>
To: Waiman Long <longman@redhat.com>
Cc: "Michal Koutný" <mkoutny@suse.com>,
"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>,
"Frederic Weisbecker" <frederic@kernel.org>,
"Marcelo Tosatti" <mtosatti@redhat.com>
Subject: Re: [PATCH v9 6/7] cgroup/cpuset: Update description of cpuset.cpus.partition in cgroup-v2.rst
Date: Wed, 15 Dec 2021 08:35:58 -1000 [thread overview]
Message-ID: <Ybo1jmNvM6sblcJq@slm.duckdns.org> (raw)
In-Reply-To: <96018978-6b7f-1e7f-1012-9df7f7996ec5@redhat.com>
Hello, Waiman.
On Wed, Dec 15, 2021 at 01:16:43PM -0500, Waiman Long wrote:
> Allowing direct transition from member to invalid partition doesn't feel
> right for me. A casual user may assume a partition is correctly formed
> without double checking the "cpuset.partition" value. Returning an error
> will prevent this kind of issue. If returning more information about the
> failure is the main reason for allowing the invalid partition transition, we
> can extend the "cpuset.partition" read syntax to also show the reason for
> the previous failure.
I don't think it's a good idea to display error messages without a way to
link the error to the one who triggered it. This is the same problem we had
with resettable counters. It only works for scenarios where one guy is
sitting in front of the computer but gets nastry for more complex scnearios
and automation.
I understand that allowing transitions to invalid state can feel jarring.
There are pros and cons to both approaches. It's similar dynamics tho.
Erroring out may be more intuitive for a casual user but makes it harder for
more complex scenarios because whether a given operation errors or not is
dependent on external asynchronous states, there's no good way of reporting
the exact nature of the error or detecting when the operation would succeed
in the future, and the error conditions are rather arbitrary.
Thanks.
--
tejun
next prev parent reply other threads:[~2021-12-15 18:36 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-05 18:32 [PATCH v9 0/7] cgroup/cpuset: Add new cpuset partition type & empty effecitve cpus Waiman Long
2021-12-05 18:32 ` [PATCH v9 1/7] cgroup/cpuset: Don't let child cpusets restrict parent in default hierarchy Waiman Long
2021-12-13 20:41 ` Tejun Heo
2021-12-15 12:23 ` Michal Koutný
2021-12-15 17:59 ` Waiman Long
2021-12-17 15:48 ` [PATCH] cgroup/cpuset: Make child cpusets restrict parents on v1 hierarchy Michal Koutný
2021-12-17 16:34 ` Waiman Long
2022-01-12 21:25 ` Tejun Heo
2021-12-05 18:32 ` [PATCH v9 2/7] cgroup/cpuset: Allow no-task partition to have empty cpuset.cpus.effective Waiman Long
2021-12-13 20:45 ` Tejun Heo
2021-12-15 3:24 ` Waiman Long
2021-12-15 10:36 ` Michal Koutný
2021-12-05 18:32 ` [PATCH v9 3/7] cgroup/cpuset: Refining features and constraints of a partition Waiman Long
2021-12-15 14:49 ` Michal Koutný
2021-12-15 16:29 ` Waiman Long
2021-12-16 9:28 ` Michal Koutný
2021-12-05 18:32 ` [PATCH v9 4/7] cgroup/cpuset: Add a new isolated cpus.partition type Waiman Long
2022-01-12 15:21 ` Peter Zijlstra
2022-01-12 15:40 ` Waiman Long
2022-01-12 21:23 ` Tejun Heo
2021-12-05 18:32 ` [PATCH v9 5/7] cgroup/cpuset: Show invalid partition reason string Waiman Long
2021-12-05 18:32 ` [PATCH v9 6/7] cgroup/cpuset: Update description of cpuset.cpus.partition in cgroup-v2.rst Waiman Long
2021-12-13 21:00 ` Tejun Heo
2021-12-15 14:44 ` Michal Koutný
2021-12-15 18:16 ` Waiman Long
2021-12-15 18:35 ` Tejun Heo [this message]
2021-12-15 18:55 ` Waiman Long
2022-01-12 21:21 ` Tejun Heo
2021-12-05 18:32 ` [PATCH v9 7/7] kselftest/cgroup: Add cpuset v2 partition root state test Waiman Long
2021-12-09 15:39 ` [PATCH v9 0/7] cgroup/cpuset: Add new cpuset partition type & empty effecitve cpus 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=Ybo1jmNvM6sblcJq@slm.duckdns.org \
--to=tj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=corbet@lwn.net \
--cc=frederic@kernel.org \
--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=longman@redhat.com \
--cc=mkoutny@suse.com \
--cc=mtosatti@redhat.com \
--cc=pauld@redhat.com \
--cc=peterz@infradead.org \
--cc=shuah@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;
as well as URLs for NNTP newsgroup(s).