Re: [RFC PATCH] mm/slab: save memory by allocating slabobj_ext array from leftover

[Vlastimil Babka <vbabka@suse.cz>]

On 6/13/25 19:47, Harry Yoo wrote:
> On Fri, Jun 13, 2025 at 09:04:34AM -0700, Christoph Lameter (Ampere) wrote:
>> On Fri, 13 Jun 2025, Harry Yoo wrote:
>> 
>> > Allocate slabobj_exts array from this unused space instead of using
>> > kcalloc(), when it is large enough.
>> 
>> How does slab debug work in this case? The object layout gets a bit
>> complicated with other metadata there as well.
> 
> Oh, the 'leftover' space I mentioned the cover letter refers to the
> wasted space after the last object in a slab, not unused bytes within
> objects.
> 
> There is no per-object metadata stored there and SLUB simply poisons the area.
> I taught slab_pad_check() to skip checking the slabobj_exts array.

I can imagine going further with this in case where leftover space in slab
isn't enough.

- indeed use per-object padding to store only single object's slabobj_ext,
if it doesn't lead to memory waste
- if not possible, but object size is small enough so there are many per
slab, maybe have one less object per slab to store the array?
- once we have struct slab decoupled from struct page, it could be part of
struct slab directly (but it would mean struct slab isn't fixed size)

Of course having multiple variants would risk slower code, so fast paths
should not be affected - we could have pointer to the 0th slabobj_ext (we
already have) and now also stride (to support the "per-object padding case"
- there's still space in struct slab right?) and then the object alloc/free
case could be oblivious to the storage method, with just a bit more
arithmetic (stride). Slab folio alloc/free would be more complicated but are
not fath path.

Also some variants would be wasteful if they need to be decided upfront (the
2nd and 3rd above) and then the array is unused, so would be only applicable
with SLAB_ACCOUNT caches (if kmemcg is active) or when memalloc profiling is
active. Shouldn't be a big issue as ad-hoc __GFP_ACCOUNT is handled by
different cache selection for kmalloc() and I don't know if anyone is
actually doing ad-hoc __GFP_ACCOUNT on named caches.