On 4/10/19 4:47 AM, Tobin C. Harding wrote: > Recently a 2 year old bug was found in the SLAB allocator that crashes > the kernel. This seems to imply that not that many people are using the > SLAB allocator.
AFAIK that bug required CONFIG_DEBUG_SLAB_LEAK, not just SLAB. That seems to imply not that many people are using SLAB when debugging and yeah, SLUB has better debugging support. But I wouldn't dare to make the broader implication :) > Currently we have 3 slab allocators. Two is company three is a crowd - > let's get rid of one. > > - The SLUB allocator has been the default since 2.6.23 Yeah, with a sophisticated reasoning :) https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a0acd820807680d2ccc4ef3448387fcdbf152c73 > - The SLOB allocator is kinda sexy. Its only 664 LOC, the general > design is outlined in KnR, and there is an optimisation taken from > Knuth - say no more. > > If you are using the SLAB allocator please speak now or forever hold your > peace ... FWIW, our enterprise kernel use it (latest is 4.12 based), and openSUSE kernels as well (with openSUSE Tumbleweed that includes latest kernel.org stables). AFAIK we don't enable SLAB_DEBUG even in general debug kernel flavours as it's just too slow. IIRC last time Mel evaluated switching to SLUB, it wasn't a clear winner, but I'll just CC him for details :) > Testing: > > Build kernel with `make defconfig` (on x86_64 machine) followed by `make > kvmconfig`. Then do the same and manually select SLOB. Boot both > kernels in Qemu. > > > thanks, > Tobin. > > > Tobin C. Harding (1): > mm: Remove SLAB allocator > > include/linux/slab.h | 26 - > kernel/cpu.c | 5 - > mm/slab.c | 4493 ------------------------------------------ > mm/slab.h | 31 +- > mm/slab_common.c | 20 +- > 5 files changed, 5 insertions(+), 4570 deletions(-) > delete mode 100644 mm/slab.c >
