On 11/8/22 21:13, Yosry Ahmed wrote: > On Tue, Nov 8, 2022 at 10:47 AM Roman Gushchin <roman.gushchin@xxxxxxxxx> wrote: >> >> 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? Yeah it was my plan to inquire about SLAB next, once SLOB's fate is settled, as I did expect greater resistance there. My hope is that if there are still workloads that benefit from SLAB's percpu arrays, we could e.g. add (per-cache opt-in) percpu arrays to SLUB, as that would be still better than having two different complete implementations. > We use SLAB at Google, but I am not the right person to answer the > question of why we can't/don't use SLUB. Adding Greg here who recently > looked into this and might have answers. I see David is already > tagged, he might have a good answer as well. Yeah, Google folks were indeed against removing SLAB due to such workloads in the past discussions. >> >> 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 >>
