Re: [LSF/MM/BPF TOPIC] SLUB: what's next?

[Alexei Starovoitov <alexei.starovoitov@gmail.com>]

On Tue, Apr 30, 2024 at 8:42 AM Vlastimil Babka <vbabka@suse.cz> wrote:
>
> Hi,
>
> I'd like to propose a session about the next steps for SLUB. This is
> different from the BOF about sheaves that Matthew suggested, which would be
> not suitable for the whole group due to being not fleshed out enough yet.
> But the session could be scheduled after the BOF so if we do brainstorm
> something promising there, the result could be discussed as part of the full
> session.
>
> Aside from that my preliminary plan is to discuss:
>
> - what was made possible by reducing the slab allocators implementations to
> a single one, and what else could be done now with a single implementation
>
> - the work-in-progress work (for now in the context of maple tree) on SLUB
> per-cpu array caches and preallocation
>
> - what functionality would SLUB need to gain so the extra caching done by
> bpf allocator on top wouldn't be necessary? (kernel/bpf/memalloc.c)

+1 to have this discussion.
Would be great to have it as part of slub.

> - similar wrt lib/objpool.c (did you even noticed it was added? :)
>
> - maybe the mempool functionality could be better integrated as well?
>
> - are there more cases where people have invented layers outside mm and that
> could be integrated with some effort? IIRC io_uring also has some caching on
> top currently...
>
> - better/more efficient memcg integration?
>
> - any other features people would like SLUB to have?
>
> Thanks,
> Vlastimil
>