Messages in this thread | | | Date | Sat, 1 Apr 2023 20:38:39 +0900 | Subject | Re: [PATCH] mm: remove all the slab allocators | From | Vlastimil Babka <> |
| |
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@linux.com> > -M: Pekka Enberg <penberg@kernel.org> > -M: David Rientjes <rientjes@google.com> > -M: Joonsoo Kim <iamjoonsoo.kim@lge.com> > -M: Andrew Morton <akpm@linux-foundation.org> > -M: Vlastimil Babka <vbabka@suse.cz> > -R: Roman Gushchin <roman.gushchin@linux.dev> > -R: Hyeonggon Yoo <42.hyeyoo@gmail.com> > -L: linux-mm@kvack.org > -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
| |