linux-kselftest.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Waiman Long <longman@redhat.com>
To: "Michal Koutný" <mkoutny@suse.com>, "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>,
	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 13:16:43 -0500	[thread overview]
Message-ID: <96018978-6b7f-1e7f-1012-9df7f7996ec5@redhat.com> (raw)
In-Reply-To: <20211215144450.GC25459@blackbody.suse.cz>

On 12/15/21 09:44, Michal Koutný wrote:
> On Mon, Dec 13, 2021 at 11:00:17AM -1000, Tejun Heo <tj@kernel.org> wrote:
>> * When a valid partition turns invalid, now we have a reliable way of
>>    discovering what exactly caused the transition. However, when a user now
>>    fails to turn a member into partition, all they get is -EINVAL and there's
>>    no way to discover why it failed and the failure conditions that -EINVAL
>>    represents aren't simple.
>>
>> * In an automated configuration scenarios, this operation mode may be
>>    difficult to make reliable and lead to sporadic failures which can be
>>    tricky to track down. The core problem is that whether a given operation
>>    succeeds or not may depend on external states (CPU on/offline) which may
>>    change asynchronously in a way that the configuring entity doesn't have
>>    any control over.
>>
>> It's true that both are existing problems with the current partition
>> interface and given that this is a pretty spcialized feature, this can be
>> okay. Michal, what are your thoughts?
> Because of asynchronous changes, the return value should not be that
> important and the user should watch cpuset.partitions for the result
> (end state) anyway.
> Furthermore, the reasons should be IMO just informative (i.e. I like
> they're not explicitly documented) and not API.
>
> But I see there could be a distinction between -EINVAL (the supplied
> input makes no sense) and -EAGAIN(?) denoting that the switch to
> partition root could not happen (due to outer constraints).
>
> You seem to propose to replace the -EAGAIN above with a success code and
> allow the switch to an invalid root.
> The action of the configuring entity would be different: retry (when?)
> vs wait till transition happens (notification) (although the immediate
> effect (the change did not happen) is same).
> I considered the two variants equal but the clear information about when
> the change can happen I'd favor the variant allowing the switch to
> invalid root now.

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.

Cheers,
Longman


  reply	other threads:[~2021-12-15 18:17 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 [this message]
2021-12-15 18:35         ` Tejun Heo
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=96018978-6b7f-1e7f-1012-9df7f7996ec5@redhat.com \
    --to=longman@redhat.com \
    --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=mkoutny@suse.com \
    --cc=mtosatti@redhat.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 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).