[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <db8843979322b9a031b5d9523b6b07dca9c13546.camel@siemens.com>
Date: Tue, 1 Oct 2024 07:32:42 +0000
From: "MOESSBAUER, Felix" <felix.moessbauer@...mens.com>
To: "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
CC: "Schmidt, Adriaan" <adriaan.schmidt@...mens.com>,
"io-uring@...r.kernel.org" <io-uring@...r.kernel.org>,
"cgroups@...r.kernel.org" <cgroups@...r.kernel.org>, "Bezdeka, Florian"
<florian.bezdeka@...mens.com>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, "axboe@...nel.dk" <axboe@...nel.dk>,
"longman@...hat.com" <longman@...hat.com>, "asml.silence@...il.com"
<asml.silence@...il.com>, "stable@...r.kernel.org" <stable@...r.kernel.org>,
"dqminh@...udflare.com" <dqminh@...udflare.com>
Subject: Re: [PATCH 6.1 0/2] io_uring/io-wq: respect cgroup cpusets
On Mon, 2024-09-30 at 21:15 +0200, Greg KH wrote:
> On Wed, Sep 11, 2024 at 06:23:14PM +0200, Felix Moessbauer wrote:
> > Hi,
> >
> > as discussed in [1], this is a manual backport of the remaining two
> > patches to let the io worker threads respect the affinites defined
> > by
> > the cgroup of the process.
> >
> > In 6.1 one worker is created per NUMA node, while in da64d6db3bd3
> > ("io_uring: One wqe per wq") this is changed to only have a single
> > worker.
> > As this patch is pretty invasive, Jens and me agreed to not
> > backport it.
> >
> > Instead we now limit the workers cpuset to the cpus that are in the
> > intersection between what the cgroup allows and what the NUMA node
> > has.
> > This leaves the question what to do in case the intersection is
> > empty:
> > To be backwarts compatible, we allow this case, but restrict the
> > cpumask
> > of the poller to the cpuset defined by the cgroup. We further
> > believe
> > this is a reasonable decision, as da64d6db3bd3 drops the NUMA
> > awareness
> > anyways.
> >
> > [1]
> > https://lore.kernel.org/lkml/ec01745a-b102-4f6e-abc9-abd636d36319@kernel.dk
>
> Why was neither of these actually tagged for inclusion in a stable
> tree?
This is a manual backport of these patches for 6.1, as the subsystem
changed significantly between 6.1 and 6.2, making an automated backport
impossible. This has been agreed on with Jens in
https://lore.kernel.org/lkml/ec01745a-b102-4f6e-abc9-abd636d36319@kernel.dk/
> Why just 6.1.y? Please submit them for all relevent kernel versions.
The original patch was tagged stable and got accepted in 6.6, 6.10 and
6.11.
Felix
>
> thanks,
>
> greg k-h
--
Siemens AG, Technology
Linux Expert Center
Powered by blists - more mailing lists