On Sat, Apr 1, 2023 at 5:47 PM Vlastimil Babka <vbabka@xxxxxxx> wrote: > > As the SLOB removal is on track and the SLAB removal is planned, I have > realized - why should we stop there and not remove also SLUB? What's a > slab allocator good for in 2023? The RAM sizes are getting larger and > the modules cheaper [1]. The object constructor trick was perhaps > interesting in 1994, but not with contemporary CPUs. So all the slab > allocator does today is just adding an unnecessary layer of complexity > over the page allocator. > > Thus, with this patch, all three slab allocators are removed, and only a > layer that passes everything to the page allocator remains in the slab.h > and mm/slab_common.c files. This will allow users to gradually > transition away and use the page allocator directly. To summarize the > advantages: > > - Less code to maintain: over 13k lines are removed by this patch, and > more could be removed if I wast^Wspent more time on this, and later as > users are transitioned from the legacy layer. This no longer needs a > separate subsystem so remove it from MAINTAINERS (I hope I can keep the > kernel.org account anyway, though). > > - Simplified MEMCG_KMEM accounting: while I was lazy and just marked it > BROKEN in this patch, it should be trivial to use the page memcg > accounting now that we use the page allocator. The per-object > accounting went through several iterations in the past and was always > complex and added overhead. Page accounting is much simpler by > comparison. > > - Simplified KASAN and friends: also was lazy in this patch so they > can't be enabled but should be easy to fix up and work just on the > page level. > > - Simpler debugging: just use debug_pagealloc=on, no need to look up the > exact syntax of the absurdly complex slub_debug parameter. This really simplifies the complexity of dealing with memory problems in the production environment, and I hope it can be merged into the linux kernel soon. Acked-by: Jeff Xie <xiehuan09@xxxxxxxxx> -- Thanks, JeffXie
