[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230623063726.ejuc6v9D@linutronix.de>
Date: Fri, 23 Jun 2023 08:37:26 +0200
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: John Johansen <john.johansen@...onical.com>
Cc: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Swapnil Sapkal <Swapnil.Sapkal@....com>,
Peter Zijlstra <peterz@...radead.org>,
linux-kernel@...r.kernel.org, linux-tip-commits@...r.kernel.org,
Aaron Lu <aaron.lu@...el.com>, x86@...nel.org,
Andrew Morton <akpm@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [tip: sched/core] sched: Fix performance regression introduced
by mm_cid
On 2023-06-21 16:59:31 [-0700], John Johansen wrote:
> > Which turned a per-cpu cache into a global memory pool protected by a spinlock. It may benefit RT, but it does not appear to be so great at scaling.
> >
> it is not. And I have a patch that needs some more formal testing for some stats.
> Ubuntu pulled it in last cycle so it has gotten a fair bit of use and is looking good
> on that end. There are probably some tweaks that can be done to improve it. The
> backoff in particular is something that has mostly been adjusted in response to some
> basic benchmarking.
>
> anyways patch below
>
> commit e057e9b47f1749882ea0efb4427d6b9671c761ab
I think I've been looking at this patch, or a former version of it, and
it looked good.
Sebastian
Powered by blists - more mailing lists