lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEr6+EBK1WUq0U9n3VwhU1+=F5X7-654v0XwqHtENOt98HU0gw@mail.gmail.com>
Date:   Sun, 2 Apr 2023 13:09:31 +0800
From:   Jeff Xie <xiehuan09@...il.com>
To:     Vlastimil Babka <vbabka@...e.cz>
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        patches@...ts.linux.dev
Subject: Re: [PATCH] mm: remove all the slab allocators

On Sat, Apr 1, 2023 at 5:47 PM Vlastimil Babka <vbabka@...e.cz> 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@...il.com>

-- 
Thanks,
JeffXie

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ