Re: [PATCH V6 9/9] mm/slab: place slabobj_ext metadata in unused space within s->size

[Harry Yoo <harry.yoo@oracle.com>]

On Tue, Jan 13, 2026 at 10:01:16PM +0900, Harry Yoo wrote:
> On Tue, Jan 13, 2026 at 01:50:31PM +0100, Vlastimil Babka wrote:
> > On 1/13/26 7:18 AM, Harry Yoo wrote:
> > > When a cache has high s->align value and s->object_size is not aligned
> > > to it, each object ends up with some unused space because of alignment.
> > > If this wasted space is big enough, we can use it to store the
> > > slabobj_ext metadata instead of wasting it.
> > > 
> > > On my system, this happens with caches like kmem_cache, mm_struct, pid,
> > > task_struct, sighand_cache, xfs_inode, and others.
> > > 
> > > To place the slabobj_ext metadata within each object, the existing
> > > slab_obj_ext() logic can still be used by setting:
> > > 
> > >   - slab->obj_exts = slab_address(slab) + (slabobj_ext offset)
> > >   - stride = s->size
> > > 
> > > slab_obj_ext() doesn't need know where the metadata is stored,
> > > so this method works without adding extra overhead to slab_obj_ext().
> > > 
> > > A good example benefiting from this optimization is xfs_inode
> > > (object_size: 992, align: 64). To measure memory savings, 2 millions of
> > > files were created on XFS.
> > > 
> > > [ MEMCG=y, MEM_ALLOC_PROFILING=n ]
> > > 
> > > Before patch (creating ~2.64M directories on xfs):
> > >   Slab:            5175976 kB
> > >   SReclaimable:    3837524 kB
> > >   SUnreclaim:      1338452 kB
> > > 
> > > After patch (creating ~2.64M directories on xfs):
> > >   Slab:            5152912 kB
> > >   SReclaimable:    3838568 kB
> > >   SUnreclaim:      1314344 kB (-23.54 MiB)
> > > 
> > > Enjoy the memory savings!
> > > 
> > > Suggested-by: Vlastimil Babka <vbabka@suse.cz>
> > > Signed-off-by: Harry Yoo <harry.yoo@oracle.com>
> > 
> > Does this look OK to you or was there a reason you didn't do it? :)
> > 
> > diff --git a/mm/slub.c b/mm/slub.c
> > index ba15df4ca417..deb69bd9646a 100644
> > --- a/mm/slub.c
> > +++ b/mm/slub.c
> > @@ -981,8 +981,7 @@ static inline bool obj_exts_in_slab(struct kmem_cache *s, struct slab *slab)
> >  #if defined(CONFIG_SLAB_OBJ_EXT) && defined(CONFIG_64BIT)
> >  static bool obj_exts_in_object(struct kmem_cache *s, struct slab *slab)
> >  {
> > -       return obj_exts_in_slab(s, slab) &&
> > -              (slab_get_stride(slab) == s->size);
> > +       return obj_exts_in_slab(s, slab) && (s->flags & SLAB_OBJ_EXT_IN_OBJ);
> 
> There was a reason why I didn't do it :)
> 
> In alloc_slab_obj_exts_early(), when both
> obj_exts_fit_within_slab_leftover() and (s->flags & SLAB_OBJ_EXT_IN_OBJ)
> returns true, it allocates the metadata from the slab's leftover space.
> 
> I noticed it as I saw a slab error in slab_pad_check() complaining that
> the padding area was overwritten, but turned out the problem was
> because obj_exts_in_object() returning true when it shouldn't.

Perhaps a comment like this?

diff --git a/mm/slub.c b/mm/slub.c
index ba15df4ca417..c40c3559039e 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -981,6 +981,15 @@ static inline bool obj_exts_in_slab(struct kmem_cache *s, struct slab *slab)
 #if defined(CONFIG_SLAB_OBJ_EXT) && defined(CONFIG_64BIT)
 static bool obj_exts_in_object(struct kmem_cache *s, struct slab *slab)
 {
+	/*
+	 * When SLAB_OBJ_EXT_IN_OBJ is set, slabobj_ext metadata can be stored
+	 * in one of two ways:
+	 * 1. As an array in the slab's leftover space (after the last object)
+	 * 2. Inline with each object (within s->size)
+	 *
+	 * The actual placement is determined by the stride size rather than
+	 * the SLAB_OBJ_EXT_IN_OBJ flag itself.
+	 */
 	return obj_exts_in_slab(s, slab) &&
 	       (slab_get_stride(slab) == s->size);
 }