Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) client-ip=2620:137:e000::3:4;
Date:   Fri, 13 Oct 2023 17:50:20 +0200
From:   Michal =?utf-8?Q?Koutn=C3=BD?= <mkoutny@suse.com>
To:     Waiman Long <longman@redhat.com>
Cc:     Tejun Heo <tj@kernel.org>, Zefan Li <lizefan.x@bytedance.com>,
        Johannes Weiner <hannes@cmpxchg.org>,
        Christian Brauner <brauner@kernel.org>,
        Jonathan Corbet <corbet@lwn.net>,
        Shuah Khan <shuah@kernel.org>, cgroups@vger.kernel.org,
        linux-kernel@vger.kernel.org, Juri Lelli <juri.lelli@redhat.com>,
        Dietmar Eggemann <dietmar.eggemann@arm.com>,
        Giuseppe Scrivano <gscrivan@redhat.com>
Subject: Re: [PATCH v8 0/7] cgroup/cpuset: Support remote partitions
Message-ID: <ahevhcy2aa7k3plmfvlepjehs6u3fun3j4oyskdz7axkhftlyi@zr3j473rciwi>
References: <20230905133243.91107-1-longman@redhat.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="tesk6d4tqdsww4u2"
Content-Disposition: inline
In-Reply-To: <20230905133243.91107-1-longman@redhat.com>
Precedence: bulk


--tesk6d4tqdsww4u2
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hello.

(I know this is heading for 6.7. Still I wanted to have a look at this
after it stabilized somehow to understand the new concept better but I
still have some questions below.)

On Tue, Sep 05, 2023 at 09:32:36AM -0400, Waiman Long <longman@redhat.com> =
wrote:
> Both scheduling and isolated partitions can be formed as a remote
> partition. A local partition can be created under a remote partition.
> A remote partition, however, cannot be formed under a local partition
> for now.
>=20
>=20
> With this patch series, we allow the creation of remote partition
> far from the root. The container management tool can manage the
> "cpuset.cpus.exclusive" file without impacting the other cpuset
> files that are managed by other middlewares. Of course, invalid
> "cpuset.cpus.exclusive" values will be rejected.

I take the example with a nested cgroup `cont` to which I want to
dedicate two CPUs (0 and 1).
IIUC, I can do this both with a chain of local root partitions or as a
single remote partion.


[chain]
  root
  |                           \
  mid1a                        mid1b
   cpuset.cpus=3D0-1              cpuset.cpus=3D2-15
   cpuset.cpus.partition=3Droot  =20
  |
  mid2
   cpuset.cpus=3D0-1
   cpuset.cpus.partition=3Droot
  |
  cont
   cpuset.cpus=3D0-1
   cpuset.cpus.partition=3Droot


[remote]
  root
  |                           \
  mid1a                        mid1b
   cpuset.cpus.exclusive=3D0-1    cpuset.cpus=3D2-15
  |
  mid2
   cpuset.cpus.exclusive=3D0-1
  |
  cont
   cpuset.cpus.exclusive=3D0-1
   cpuset.cpus.partition=3Droot

In the former case I must configure cpuset.cpus and
cpuset.cpus.partition along the whole path and in the second case
cpuset.cpus.exclusive still along the whole path and root at the bottom
only.

What is the difference between the two configs above?
(Or can you please give an example where the remote partitions are
better illustrated?)

<snip>
> Modern container orchestration tools like Kubernetes use the cgroup
> hierarchy to manage different containers. And it is relying on other
> middleware like systemd to help managing it. If a container needs to
> use isolated CPUs, it is hard to get those with the local partitions
> as it will require the administrative parent cgroup to be a partition
> root too which tool like systemd may not be ready to manage.

Such tools ready aren't ready to manage cpuset.cpus.exclusive, are they?
IOW tools need to distinguish exclusive and "shared" CPUs which is equal
to distinguishing root and member partitions.

Thanks,
Michal


--tesk6d4tqdsww4u2
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQQpEWyjXuwGT2dDBqAGvrMr/1gcjgUCZSlnOgAKCRAGvrMr/1gc
jlo1AP4xYSAUf4DNG5nuDm9LyX+YsGRZ3bq7u4QtsOcCrbBDcQEAxQyx0Jkugln1
c2iV+v7jMcqrtN8iFmXXCc/E1ZE49Qs=
=9/XE
-----END PGP SIGNATURE-----

--tesk6d4tqdsww4u2--