[LSF/MM/BPF TOPIC] SLAB BOF

[LSF/MM/BPF TOPIC] SLAB BOF

[Matthew Wilcox]

I have a fairly radical idea for a new slab allocator design which
I want to sit down with Vlastimil and a whiteboard to flesh out.
Obviously the two of us could just sneak off somewhere, but it'd
probably make more sense to schedule this as a BOF.

The basic idea is to decouple the objects from the page they reside in.
Instead of having a struct slab to organise the objects on this page,
we organise the objects into sheaves.  A sheaf always contains objects
from the same NUMA node, but not necessarily the same page.  For each
kmem_cache, there is a per-NUMA-node barn which the per-CPU front end of
the slab allocator will request full sheaves from and give full sheaves
back to.  If we RCU-free an object, that goes to the per-CPU rcu-freeing
sheaf, which is handed to RCU once full.

The obvious objection to all of this is that the story for reclaiming
pages from slab is pretty awful.  I'd hope to brainstorm some idea for
improving that (perhaps in the construction of the barn where we could
pull sheaves part and put them back together in some kind of order?)

Re: [LSF/MM/BPF TOPIC] SLAB BOF

[David Hildenbrand]

On 22.04.24 16:23, Matthew Wilcox wrote:
> I have a fairly radical idea for a new slab allocator design which
> I want to sit down with Vlastimil and a whiteboard to flesh out.
> Obviously the two of us could just sneak off somewhere, but it'd
> probably make more sense to schedule this as a BOF.
> 
> The basic idea is to decouple the objects from the page they reside in.
> Instead of having a struct slab to organise the objects on this page,
> we organise the objects into sheaves.  A sheaf always contains objects
> from the same NUMA node, but not necessarily the same page.  For each
> kmem_cache, there is a per-NUMA-node barn which the per-CPU front end of
> the slab allocator will request full sheaves from and give full sheaves
> back to.  If we RCU-free an object, that goes to the per-CPU rcu-freeing
> sheaf, which is handed to RCU once full.
> 
> The obvious objection to all of this is that the story for reclaiming
> pages from slab is pretty awful.  I'd hope to brainstorm some idea for
> improving that (perhaps in the construction of the barn where we could
> pull sheaves part and put them back together in some kind of order?)

Just as a side note, I would be interested into something that can 
easily reclaim pages from slab in a specific physical memory area. 
Target use cases are around alloc_contig_range(), memory offlining an 
similar.

... but IIUC, the barn/sheep approach wouldn't make that any easier, right?

-- 
Cheers,

David / dhildenb

Re: [LSF/MM/BPF TOPIC] SLAB BOF

[Matthew Wilcox]

On Wed, Apr 24, 2024 at 02:52:41PM +0200, David Hildenbrand wrote:
> Just as a side note, I would be interested into something that can easily
> reclaim pages from slab in a specific physical memory area. Target use cases
> are around alloc_contig_range(), memory offlining an similar.
> 
> ... but IIUC, the barn/sheep approach wouldn't make that any easier, right?

It'll make it harder, tbh, because today we track each object from its
struct slab.  If we want to do something like this, we need to do a few
things:

 - Send an IPI to all CPUs to let them know they need to return
   their delayed-free sheaf immediately
 - CPUs on the node which owns the memory we're trying to reclaim also
   need to search their allocation sheaf for objects that we no longer
   want to allocate

But I fear this is pointless.  Unless we can get _all_ objects in the
range back, we may as well get none of them.  Which means we need a
mechanism for asking the user of the kmem_cache to reallocate specific
objects.  We've looked at something like that before, most recently:

https://lore.kernel.org/linux-mm/20190520054017.32299-11-tobin@kernel.org/

(you can forget about ever reclaiming from kmalloc slabs, but a real slab
cache could be movable)