[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <390d6318-08f3-403b-bf96-4675a0d1fe98@suse.cz>
Date: Thu, 29 Jan 2026 16:28:01 +0100
From: Vlastimil Babka <vbabka@...e.cz>
To: Hao Li <hao.li@...ux.dev>
Cc: Harry Yoo <harry.yoo@...cle.com>, Petr Tesarik <ptesarik@...e.com>,
Christoph Lameter <cl@...two.org>, David Rientjes <rientjes@...gle.com>,
Roman Gushchin <roman.gushchin@...ux.dev>,
Andrew Morton <akpm@...ux-foundation.org>,
Uladzislau Rezki <urezki@...il.com>,
"Liam R. Howlett" <Liam.Howlett@...cle.com>,
Suren Baghdasaryan <surenb@...gle.com>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Alexei Starovoitov <ast@...nel.org>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, linux-rt-devel@...ts.linux.dev,
bpf@...r.kernel.org, kasan-dev@...glegroups.com,
kernel test robot <oliver.sang@...el.com>, stable@...r.kernel.org,
"Paul E. McKenney" <paulmck@...nel.org>
Subject: Re: [PATCH v4 00/22] slab: replace cpu (partial) slabs with sheaves
On 1/29/26 16:18, Hao Li wrote:
> Hi Vlastimil,
>
> I conducted a detailed performance evaluation of the each patch on my setup.
Thanks! What was the benchmark(s) used? Importantly, does it rely on
vma/maple_node objects? So previously those would become kind of double
cached by both sheaves and cpu (partial) slabs (and thus hopefully benefited
more than they should) since sheaves introduction in 6.18, and now they are
not double cached anymore?
> During my tests, I observed two points in the series where performance
> regressions occurred:
>
> Patch 10: I noticed a ~16% regression in my environment. My hypothesis is
> that with this patch, the allocation fast path bypasses the percpu partial
> list, leading to increased contention on the node list.
That makes sense.
> Patch 12: This patch seems to introduce an additional ~9.7% regression. I
> suspect this might be because the free path also loses buffering from the
> percpu partial list, further exacerbating node list contention.
Hmm yeah... we did put the previously full slabs there, avoiding the lock.
> These are the only two patches in the series where I observed noticeable
> regressions. The rest of the patches did not show significant performance
> changes in my tests.
>
> I hope these test results are helpful.
They are, thanks. I'd however hope it's just some particular test that has
these regressions, which can be explained by the loss of double caching.
Powered by blists - more mailing lists