linux-kernel - Re: [PATCH v4 00/22] slab: replace cpu (partial) slabs with sheaves

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <2abde505-1e35-8d74-2806-7a3cd430e306@gentwo.org>
Date: Wed, 4 Feb 2026 10:24:46 -0800 (PST)
From: "Christoph Lameter (Ampere)" <cl@...two.org>
To: Vlastimil Babka <vbabka@...e.cz>
cc: Hao Li <hao.li@...ux.dev>, Harry Yoo <harry.yoo@...cle.com>, 
    Petr Tesarik <ptesarik@...e.com>, 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 Wed, 4 Feb 2026, Vlastimil Babka wrote:

> > So I think the performance of the percpu partial list and the sheaves mechanism
> > is roughly the same, which is consistent with our expectations.
>
> Thanks!

There are other considerations that usually do not show up well in
benchmark tests.

The sheaves cannot do the spatial optimizations that cpu partial lists
provide. Fragmentation in slab caches (and therefore the nubmer of
partial slab pages) will increase since

1. The objects are not immediately returned to their slab pages but end up
in some queuing structure.

2. Available objects from a single slab page are not allocated in sequence
to empty partial pages and remove the page from the partial lists.

Objects are put into some queue on free and are processed on a FIFO basis.
Objects allocated may come from lots of different slab pages potentially
increasing TLB pressure.