[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YqdzuSQuAeiPXQvy@slm.duckdns.org>
Date: Mon, 13 Jun 2022 07:28:25 -1000
From: Tejun Heo <tj@...nel.org>
To: Michal Koutný <mkoutny@...e.com>
Cc: Waiman Long <longman@...hat.com>,
Zefan Li <lizefan.x@...edance.com>,
Johannes Weiner <hannes@...xchg.org>,
Jonathan Corbet <corbet@....net>,
Shuah Khan <shuah@...nel.org>, cgroups@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
linux-kselftest@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
Roman Gushchin <guro@...com>, Phil Auld <pauld@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Juri Lelli <juri.lelli@...hat.com>,
Frederic Weisbecker <frederic@...nel.org>,
Marcelo Tosatti <mtosatti@...hat.com>
Subject: Re: [PATCH v11 7/8] cgroup/cpuset: Update description of
cpuset.cpus.partition in cgroup-v2.rst
Hello,
On Mon, Jun 13, 2022 at 04:24:52PM +0200, Michal Koutný wrote:
> On Sun, Jun 12, 2022 at 05:12:51PM -1000, Tejun Heo <tj@...nel.org> wrote:
> > On Sun, Jun 12, 2022 at 11:02:38PM -0400, Waiman Long wrote:
> > > That is the behavior enforced by setting the CPU_EXCLUSIVE bit in cgroup v1.
> > > I haven't explicitly change it to make it different in cgroup v2. The major
> > > reason is that I don't want change to one cpuset to affect a sibling
> > > partition as it may make the code more complicate to validate if a partition
> > > is valid.
> >
> > If at all possible, I'd really like to avoid situations where a parent can't
> > withdraw resources due to something that a descendant does.
>
> My understanding of the discussed paragraph is that the changes are only
> disallowed only among siblings on one level (due to exclusivity rule,
> checked in validate_change()). A change in parent won't affect
> (non)exclusivity of (valid) children so it's simply allowed.
>
> So the docs (and implementation by a quick look) is sensible.
I see. Is this part even necessary? All the .cpus files of the siblings are
owned by the parent who's responsible for configuring both the mode that the
cgroup subtree is gonna be in and their cpumasks. Given that all the other
errors it can make are notified through "invalid (REASON)" in the mode file,
wouldn't it fit better to notify cpus configuration error the same way too?
Thanks.
--
tejun
Powered by blists - more mailing lists