All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michal Koutný" <mkoutny@suse.com>
To: Tejun Heo <tj@kernel.org>
Cc: Waiman Long <longman@redhat.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 v11 7/8] cgroup/cpuset: Update description of cpuset.cpus.partition in cgroup-v2.rst
Date: Thu, 30 Jun 2022 16:32:11 +0200	[thread overview]
Message-ID: <20220630143211.GA22105@blackbody.suse.cz> (raw)
In-Reply-To: <YroApRMPV/6zO5I8@mtj.duckdns.org>

On Tue, Jun 28, 2022 at 04:10:29AM +0900, Tejun Heo <tj@kernel.org> wrote:
> What I'm trying to say is that cpuset.cpus of child_1 and child_2 are
> owned by the parent,

Cf

On Mon, Jun 13, 2022 at 08:00:56AM -1000, Tejun Heo <tj@kernel.org> wrote:
> On Mon, Jun 13, 2022 at 07:55:49PM +0200, Michal Koutný wrote:
> > I don't think child_*/cpuset.cpus must be owned by root.
> 
> I meant the parent.

I'm slightly confused.

> so a feature which blocks siblings from intersecting each other
> doesn't make whole lot of sense because all those files are under the
> control of the parent who would have the power to enable or disable
> the restrition anyway.

file				owner
parent/				user (mkdir)
`- cpuset.cpus			root
`- cpuset.cpus.partition	root	(P)
`- child_1/			user
  ` cpuset.cpus			user	(*)
`- child_2/			user
  ` cpuset.cpus			user	(*)

The writes to child cpuset.cpus may/may not invalidate parent's (P)
partition validity (whether a cpu is left to it to host possible tasks).
child_1 vs child_2 overlap affects only whether the children cgroups are
a valid partition.

I think you mean: writes to children cpuset.cpus should be allowed,
possible exclusivity violation should be reported in
parent/cpuset.cpus.partition.

What I thought was OK: prevent (fail) writes to children cpuset.cpus
that'd violate the exclusivity (or would take the last cpu from parent
if it's necessary to host a task).
IMO, it's similar to failed writes to parent/cgroup.subtree_control in a
delegated subtree if the parent still has some tasks (that'd violate
internal node constraint).

What I think might still be OK: allow writes to children cpuset.cpus
that violate exclusivity and report that in children's
cpuset.cpus.partition. Writes that'd take last cpu from parent should
still fail (similar to the failing subtree_control writes above).

Hope that clarifies,
Michal

  reply	other threads:[~2022-06-30 14:37 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-10 15:34 [PATCH v11 0/8] cgroup/cpuset: cpu partition code enhancements Waiman Long
2022-05-10 15:34 ` [PATCH v11 1/8] cgroup/cpuset: Add top_cpuset check in update_tasks_cpumask() Waiman Long
2022-05-10 15:34   ` Waiman Long
2022-05-10 15:34 ` [PATCH v11 2/8] cgroup/cpuset: Miscellaneous cleanups & add helper functions Waiman Long
2022-05-10 15:34 ` [PATCH v11 3/8] cgroup/cpuset: Allow no-task partition to have empty cpuset.cpus.effective Waiman Long
2022-06-12 17:40   ` Tejun Heo
2022-06-12 17:41     ` Tejun Heo
2022-06-13  2:53       ` Waiman Long
2022-06-13  2:55         ` Tejun Heo
2022-06-13  3:04           ` Waiman Long
2022-06-13  3:04             ` Waiman Long
2022-06-13 14:02           ` Michal Koutný
2022-06-13 14:02             ` Michal Koutný
2022-06-13 16:47             ` Waiman Long
2022-06-13 16:47               ` Waiman Long
2022-06-13 17:23               ` Tejun Heo
2022-06-13  2:50     ` Waiman Long
2022-05-10 15:34 ` [PATCH v11 4/8] cgroup/cpuset: Relax constraints to partition & cpus changes Waiman Long
2022-05-10 15:34   ` Waiman Long
2022-05-10 15:34 ` [PATCH v11 5/8] cgroup/cpuset: Add a new isolated cpus.partition type Waiman Long
2022-05-10 15:34   ` Waiman Long
2022-05-10 15:34 ` [PATCH v11 6/8] cgroup/cpuset: Show invalid partition reason string Waiman Long
2022-05-10 15:34 ` [PATCH v11 7/8] cgroup/cpuset: Update description of cpuset.cpus.partition in cgroup-v2.rst Waiman Long
2022-06-12 17:49   ` Tejun Heo
2022-06-13  3:02     ` Waiman Long
2022-06-13  3:12       ` Tejun Heo
2022-06-13  3:12         ` Tejun Heo
2022-06-13 13:18         ` Waiman Long
2022-06-13 17:06           ` Waiman Long
2022-06-13 14:24         ` Michal Koutný
2022-06-13 14:24           ` Michal Koutný
2022-06-13 17:28           ` Tejun Heo
2022-06-13 17:55             ` Michal Koutný
2022-06-13 18:00               ` Tejun Heo
2022-06-13 18:00                 ` Tejun Heo
2022-06-14 11:53                 ` Michal Koutný
2022-06-14 11:53                   ` Michal Koutný
2022-06-27 19:10                   ` Tejun Heo
2022-06-27 19:10                     ` Tejun Heo
2022-06-30 14:32                     ` Michal Koutný [this message]
2022-06-30 22:53                       ` Tejun Heo
2022-05-10 15:34 ` [PATCH v11 8/8] kselftest/cgroup: Add cpuset v2 partition root state test Waiman Long
2022-05-21 10:24   ` Muhammad Usama Anjum
2022-05-21 10:24     ` Muhammad Usama Anjum
2022-05-22  2:40     ` Waiman Long
2022-05-20 16:00 ` [PATCH v11 0/8] cgroup/cpuset: cpu partition code enhancements Sebastian Andrzej Siewior
2022-05-20 16:46   ` Waiman Long
2022-05-24 16:48     ` Sebastian Andrzej Siewior

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=20220630143211.GA22105@blackbody.suse.cz \
    --to=mkoutny@suse.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=longman@redhat.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 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.