Re: [PATCH 0/8] mm/slab: Support selecting slab hardening features at boot

[Chris Down <chris@chrisdown.name>]

Hi Vlastimil,

Vlastimil Babka (SUSE) writes:
>These two should be only a small cpu overhead, which is why distros
>generally enable them [1]. Also the code basically only runs in slowpaths
>because percpu caching doesn't use freelists. It's possible the static key
>conversion doesn't help anything. You could try to measure the impact, I'd
>be surprised perhaps :)

Well I measured it, and you're right :-)

I built kernels from d15d7703166d ("mm/slub: initialize the free pointer of the 
bootstrap kmem_cache_node") toggling SLAB_FREELIST_HARDENED and 
SLAB_FREELIST_RANDOM, with SLAB_BUCKETS, KMALLOC_PARTITION_CACHES and 
SHUFFLE_PAGE_ALLOCATOR pinned off on an AMD Genoa.

With both on vs both off, sched messaging, perf bench syscall fork, a 
tinyconfig kernel build and netperf over lo all moved by less than 0.8%, which 
is within the noise here. So the slowpaths do pay, as you'd expect. Here's the 
change in ns/object vs both off, over 64, 256 and 1024 byte objects:

                       hard           rand          both
   batch alloc      +5.5..+7.8%    +7.6..+12.5%   +13..+15%
   bulk alloc       -2.0..+3.9%    +28..+32%      +33..+38%
   batch/bulk free  +0.5..+4.6%    -1.7..+0.6%    +0.8..+4.5%

These are from a small module which just does ktime_get_ns() on one pinned CPU.  
batch allocates 4096 objects with kmalloc() and then frees them 1000 times.  
bulk does the same with kmem_cache_alloc_bulk() and kmem_cache_free_bulk() on a 
private cache, so it keeps creating new slabs, which is where the random seq 
gets applied.

So for us the right answer is to likely just turn these two on rather than make 
them switchable, too.

>Maybe we should just make them default=y.

Agreed. In v2 I'll replace the boot parameters for these two with patches which 
make them default y, and keep slab_buckets= and kmalloc_partition=.

Thank you for spotting this!