linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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>,
	linux-kernel@vger.kernel.org, cgroups@vger.kernel.org,
	linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org,
	"Juri Lelli" <juri.lelli@redhat.com>,
	"Valentin Schneider" <vschneid@redhat.com>,
	"Frederic Weisbecker" <frederic@kernel.org>,
	"Mrunal Patel" <mpatel@redhat.com>,
	"Ryan Phillips" <rphillips@redhat.com>,
	"Brent Rowsell" <browsell@redhat.com>,
	"Peter Hunt" <pehunt@redhat.com>, "Phil Auld" <pauld@redhat.com>
Subject: Re: [RFC PATCH 0/5] cgroup/cpuset: A new "isolcpus" paritition
Date: Mon, 22 May 2023 09:49:38 -1000	[thread overview]
Message-ID: <ZGvHUjOCjwat91Gq@slm.duckdns.org> (raw)
In-Reply-To: <405b2805-538c-790b-5bf8-e90d3660f116@redhat.com>

Hello, Waiman.

On Sun, May 07, 2023 at 09:03:44PM -0400, Waiman Long wrote:
...
>   cpuset.cpus.reserve
>     A read-write multiple values file which exists only on root
>     cgroup.
> 
>     It lists all the CPUs that are reserved for adjacent and remote
>     partitions created in the system.  See the next section for
>     more information on what an adjacent or remote partitions is.
> 
>     Creation of adjacent partition does not require touching this
>     control file as CPU reservation will be done automatically.
>     In order to create a remote partition, the CPUs needed by the
>     remote partition has to be written to this file first.
> 
>     A "+" prefix can be used to indicate a list of additional
>     CPUs that are to be added without disturbing the CPUs that are
>     originally there.  For example, if its current value is "3-4",
>     echoing ""+5" to it will change it to "3-5".
>
>     Once a remote partition is destroyed, its CPUs have to be
>     removed from this file or no other process can use them.  A "-"
>     prefix can be used to remove a list of CPUs from it.  However,
>     removing CPUs that are currently used in existing partitions
>     may cause those partitions to become invalid.  A single "-"
>     character without any number can be used to indicate removal
>     of all the free CPUs not allocated to any partitions to avoid
>     accidental partition invalidation.

Why is the syntax different from .cpus? Wouldn't it be better to keep them
the same?

>   cpuset.cpus.partition
>     A read-write single value file which exists on non-root
>     cpuset-enabled cgroups.  This flag is owned by the parent cgroup
>     and is not delegatable.
> 
>     It accepts only the following input values when written to.
> 
>       ==========    =====================================
>       "member"    Non-root member of a partition
>       "root"    Partition root
>       "isolated"    Partition root without load balancing
>       ==========    =====================================
> 
>     A cpuset partition is a collection of cgroups with a partition
>     root at the top of the hierarchy and its descendants except
>     those that are separate partition roots themselves and their
>     descendants.  A partition has exclusive access to the set of
>     CPUs allocated to it.  Other cgroups outside of that partition
>     cannot use any CPUs in that set.
> 
>     There are two types of partitions - adjacent and remote.  The
>     parent of an adjacent partition must be a valid partition root.
>     Partition roots of adjacent partitions are all clustered around
>     the root cgroup.  Creation of adjacent partition is done by
>     writing the desired partition type into "cpuset.cpus.partition".
> 
>     A remote partition does not require a partition root parent.
>     So a remote partition can be formed far from the root cgroup.
>     However, its creation is a 2-step process.  The CPUs needed
>     by a remote partition ("cpuset.cpus" of the partition root)
>     has to be written into "cpuset.cpus.reserve" of the root
>     cgroup first.  After that, "isolated" can be written into
>     "cpuset.cpus.partition" of the partition root to form a remote
>     isolated partition which is the only supported remote partition
>     type for now.
> 
>     All remote partitions are terminal as adjacent partition cannot
>     be created underneath it.

Can you elaborate this extra restriction a bit further?

In general, I think it'd be really helpful if the document explains the
reasoning behind the design decisions. ie. Why is reserving for? What
purpose does it serve that the regular isolated ones cannot? That'd help
clarifying the design decisions.

Thanks.

-- 
tejun

  reply	other threads:[~2023-05-22 19:49 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-12 15:37 [RFC PATCH 0/5] cgroup/cpuset: A new "isolcpus" paritition Waiman Long
2023-04-12 19:28 ` Tejun Heo
     [not found]   ` <1ce6a073-e573-0c32-c3d8-f67f3d389a28@redhat.com>
2023-04-12 20:22     ` Tejun Heo
2023-04-12 20:33       ` Waiman Long
2023-04-13  0:03         ` Tejun Heo
2023-04-13  0:26           ` Waiman Long
2023-04-13  0:33             ` Tejun Heo
2023-04-13  0:55               ` Waiman Long
2023-04-13  1:17                 ` Tejun Heo
2023-04-13  1:55                   ` Waiman Long
2023-04-14  1:22                     ` Waiman Long
2023-04-14 16:54                       ` Tejun Heo
2023-04-14 17:29                         ` Waiman Long
2023-04-14 17:34                           ` Tejun Heo
2023-04-14 17:38                             ` Waiman Long
2023-04-14 19:06                               ` Waiman Long
2023-05-02 18:01                                 ` Michal Koutný
2023-05-02 21:26                                   ` Waiman Long
2023-05-02 22:27                                     ` Michal Koutný
2023-05-04  3:01                                       ` Waiman Long
2023-05-05 16:03                                         ` Tejun Heo
2023-05-05 16:25                                           ` Waiman Long
2023-05-08  1:03                                             ` Waiman Long
2023-05-22 19:49                                               ` Tejun Heo [this message]
2023-05-28 21:18                                                 ` Waiman Long
2023-06-05 18:03                                                   ` Tejun Heo
2023-06-05 20:00                                                     ` Waiman Long
2023-06-05 20:27                                                       ` Tejun Heo
2023-06-06  2:47                                                         ` Waiman Long
2023-06-06 19:58                                                           ` Tejun Heo
2023-06-06 20:11                                                             ` Waiman Long
2023-06-06 20:13                                                               ` Tejun Heo

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=ZGvHUjOCjwat91Gq@slm.duckdns.org \
    --to=tj@kernel.org \
    --cc=browsell@redhat.com \
    --cc=cgroups@vger.kernel.org \
    --cc=corbet@lwn.net \
    --cc=frederic@kernel.org \
    --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=mpatel@redhat.com \
    --cc=pauld@redhat.com \
    --cc=pehunt@redhat.com \
    --cc=rphillips@redhat.com \
    --cc=shuah@kernel.org \
    --cc=vschneid@redhat.com \
    /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).