Blah, sorry, lets try this.
https://docs.google.com/spreadsheets/d/e/2PACX-1vS1uiw85AIpzgcVlvNlDCD9PuCIubiaJvBrKIC5OyAQURZHogOuCtpFNsC-zGHZ4-XNKJVcGgkpL-KH/pubhtml

On Wed, Mar 22, 2023 at 9:02 AM Hyeonggon Yoo [off-list ref] wrote:

On Wed, Mar 22, 2023 at 08:15:28AM -0400, Binder Makin wrote:

quoted

Was looking at SLAB removal and started by running A/B tests of SLAB vs
SLUB.  Please note these are only preliminary results.

These were run using 6.1.13 configured for SLAB/SLUB.
Machines were standard datacenter servers.

Hackbench shows completion time, so smaller is better.
On all others larger is better.
https://docs.google.com/spreadsheets/d/e/2PACX-1vQ47Mekl8BOp3ekCefwL6wL8SQiv6Qvp5avkU2ssQSh41gntjivE-aKM4PkwzkC4N_s_MxUdcsokhhz/pubhtml

Some notes:
SUnreclaim and SReclaimable shows unreclaimable and reclaimable memory.
Substantially higher with SLUB, but I believe that is to be expected.

Various results showing a 5-10% degradation with SLUB.  That feels
concerning to me, but I'm not sure what others' tolerance would be.

Hello Binder,

Thank you for sharing the data on which workloads
SLUB performs worse than SLAB. This information is critical for
improving SLUB and deprecating SLAB.

By the way, it appears that the spreadsheet is currently set to private.
Could you make it public for me to access?

I am really interested in performing similar experiments on my machines
to obtain comparable data that can be utilized to enhance SLUB.

Thanks,
Hyeonggon

quoted

redis results on AMD show some pretty bad degredations.  10-20% range
netpipe on Intel also has issues.. 10-17%

On Tue, Mar 14, 2023 at 4:05 AM Vlastimil Babka [off-list ref] wrote:

quoted

As you're probably aware, my plan is to get rid of SLOB and SLAB, leaving
only SLUB going forward. The removal of SLOB seems to be going well, there
were no objections to the deprecation and I've posted v1 of the removal
itself [1] so it could be in -next soon.

The immediate benefit of that is that we can allow kfree() (and
kfree_rcu())
to free objects from kmem_cache_alloc() - something that IIRC at least xfs
people wanted in the past, and SLOB was incompatible with that.

For SLAB removal I haven't yet heard any objections (but also didn't
deprecate it yet) but if there are any users due to particular workloads
doing better with SLAB than SLUB, we can discuss why those would regress
and
what can be done about that in SLUB.

Once we have just one slab allocator in the kernel, we can take a closer
look at what the users are missing from it that forces them to create own
allocators (e.g. BPF), and could be considered to be added as a generic
implementation to SLUB.

Thanks,
Vlastimil

[1] https://lore.kernel.org/all/20230310103210.22372-1-vbabka@suse.cz/ (local)