[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y2qkIrk+a9v7tAQZ@P9FQF9L96D.lan>
Date: Tue, 8 Nov 2022 10:46:58 -0800
From: Roman Gushchin <roman.gushchin@...ux.dev>
To: Vlastimil Babka <vbabka@...e.cz>
Cc: Christoph Lameter <cl@...ux.com>,
David Rientjes <rientjes@...gle.com>,
Joonsoo Kim <iamjoonsoo.kim@....com>,
Pekka Enberg <penberg@...nel.org>,
Hyeonggon Yoo <42.hyeyoo@...il.com>,
Matthew Wilcox <willy@...radead.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Catalin Marinas <catalin.marinas@....com>,
Rustam Kovhaev <rkovhaev@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: Deprecating and removing SLOB
On Tue, Nov 08, 2022 at 04:55:29PM +0100, Vlastimil Babka wrote:
> Hi,
>
> as we all know, we currently have three slab allocators. As we discussed at
> LPC [1], it is my hope that one of these allocators has a future, and two of
> them do not.
>
> The unsurprising reasons include code maintenance burden, other features
> compatible with only a subset of allocators (or more effort spent on the
> features), blocking API improvements (more on that below), and my inability
> to pronounce SLAB and SLUB in a properly distinguishable way, without
> resorting to spelling out the letters.
>
> I think (but may be proven wrong) that SLOB is the easier target of the two
> to be removed, so I'd like to focus on it first.
Great!
SLOB is not supported by the kernel memory accounting code, so if we'll
deprecate SLOB, we can remove all those annoying ifndefs.
But I wonder if we can deprecate SLAB too? Or at least use the moment to
ask every non-SLUB user on why they can't/don't want to use SLUB.
Are there any known advantages of SLAB over SLUB?
Also, for memory-constrained users we might want to add some guide on how
to configure SLUB to minimize the memory footprint.
Thank you!
Roman
Powered by blists - more mailing lists