Re: [PATCH 0/3] slab: support memoryless nodes with sheaves

From: Jon Hunter

Date: Thu Apr 09 2026 - 16:02:50 EST



On 08/04/2026 15:06, Hao Li wrote:
On Wed, Apr 08, 2026 at 02:04:54PM +0100, Jon Hunter wrote:
Hi Vlastimil,

On 11/03/2026 17:22, Vlastimil Babka (SUSE) wrote:
On 3/11/26 10:49, Ming Lei wrote:
On Wed, Mar 11, 2026 at 09:25:54AM +0100, Vlastimil Babka (SUSE) wrote:
This is the draft patch from [1] turned into a proper series with
incremental changes. It's based on v7.0-rc3. It's too intrusive for a
7.0 hotfix, so we'll only be able to fix/reduce the regression in 7.1. I
hope it's acceptable given it's a non-standard configuration, 7.0 is not
a LTS, and it's a perf regression, not functionality.

Ming can you please retest this on top of v7.0-rc3, which already has
fb1091febd66 ("mm/slab: allow sheaf refill if blocking is not
allowed"). Separate data point for v7.0-rc3 could be also useful.

[1] https://lore.kernel.org/all/c6a01f7e-c6eb-454b-9b9e-734526dd659d@xxxxxxxxxx/

Signed-off-by: Vlastimil Babka (SUSE) <vbabka@xxxxxxxxxx>
---
Vlastimil Babka (SUSE) (3):
slab: decouple pointer to barn from kmem_cache_node
slab: create barns for online memoryless nodes
slab: free remote objects to sheaves on memoryless nodes

Hi Vlastimil and Guys,

I re-run the test case used in https://lore.kernel.org/all/aZ0SbIqaIkwoW2mB@fedora/

- v6.19-rc5: 34M

- 815c8e35511d Merge branch 'slab/for-7.0/sheaves' into slab/for-next: 13M

- v7.0-rc3: 13M

Thanks, that's in line with your previous testing of "mm/slab: allow sheaf
refill if blocking is not allowed" making no difference here. At least we
just learned it helps other benchmarks :)

- v7.0-rc3 + the three patches: 24M

OK. So now it might be really the total per-cpu caching capacity difference.


I have also observed a performance regresssion for Linux v7.0-rc for some
graphics related tests we run. I bisected to ...

# first bad commit: [e47c897a29491ade20b27612fdd3107c39a07357] slab: add
sheaves to most caches

Hi, Jon

Thanks for the reporting.
This first bad commit is surprising. In theory, this commit seems couldn't hurt
performance.
Could you possibly manually switch commits to verify this bad commit again,
without using git bisect?

So I went back and checked out commit e47c897a29491ade20b27612fdd3107c39a07357 ("slab: add
sheaves to most caches") confirmed that the problem exists there and then reverted that and confirmed that I no longer see the problem.

Jon

--
nvpublic