Re: [PATCH] mm: remove all the slab allocators
From: Vlastimil Babka
Date: Sat Apr 01 2023 - 07:38:42 EST
On 4/1/2023 6:46 PM, Vlastimil Babka 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.
Oh my goodness, I am on vacation now and looks like someone is
pretending to be me.
Probably my account was hacked. Please ignore this whole thread.
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.
- Speed: didn't measure, but for the page allocator we have pcplists, so
it should scale just fine. No need for the crazy SLUB's cmpxchg_double()
craziness. Maybe that thing could be now removed too? Yeah I can see
just two remaining users.
Any downsides? Let's look at memory usage after virtme boot:
Before (with SLUB):
Slab: 26304 kB
After:
Slab: 295592 kB
Well, that's not so bad, see [1].
[1] https://www.theregister.com/2023/03/29/dram_prices_crash/
---
MAINTAINERS | 15 -
include/linux/slab.h | 211 +-
include/linux/slab_def.h | 124 -
include/linux/slub_def.h | 198 --
init/Kconfig | 2 +-
mm/Kconfig | 134 +-
mm/Makefile | 10 -
mm/slab.c | 4046 ------------------------
mm/slab.h | 426 ---
mm/slab_common.c | 876 ++---
mm/slob.c | 757 -----
mm/slub.c | 6506 --------------------------------------
12 files changed, 228 insertions(+), 13077 deletions(-)
delete mode 100644 include/linux/slab_def.h
delete mode 100644 include/linux/slub_def.h
delete mode 100644 mm/slab.c
delete mode 100644 mm/slob.c
delete mode 100644 mm/slub.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 1dc8bd26b6cf..40b05ad03cd0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -19183,21 +19183,6 @@ F: drivers/irqchip/irq-sl28cpld.c
F: drivers/pwm/pwm-sl28cpld.c
F: drivers/watchdog/sl28cpld_wdt.c
-SLAB ALLOCATOR
-M: Christoph Lameter <cl@xxxxxxxxx>
-M: Pekka Enberg <penberg@xxxxxxxxxx>
-M: David Rientjes <rientjes@xxxxxxxxxx>
-M: Joonsoo Kim <iamjoonsoo.kim@xxxxxxx>
-M: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
-M: Vlastimil Babka <vbabka@xxxxxxx>
-R: Roman Gushchin <roman.gushchin@xxxxxxxxx>
-R: Hyeonggon Yoo <42.hyeyoo@xxxxxxxxx>
-L: linux-mm@xxxxxxxxx
-S: Maintained
-T: git git://git.kernel.org/pub/scm/linux/kernel/git/vbabka/slab.git
-F: include/linux/sl?b*.h
-F: mm/sl?b