On Wed, Apr 10, 2019 at 10:02:36AM +0200, Vlastimil Babka wrote: > 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 :) Point noted. > > 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. Ok, so that probably already kills this. Thanks for the response. No flaming, no swearing, man! and they said LKML was a harsh environment ... > IIRC last time Mel evaluated switching to SLUB, it wasn't a clear > winner, but I'll just CC him for details :) Probably don't need to take up too much of Mel's time, if we have one user in production we have to keep it, right. Thanks for your time Vlastimil. Tobin
