linux-kernel - Re: [RFC PATCH V3 7/7] mm/slab: place slabobj_ext metadata in unused space within s->size

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aUkn-SV9QjicEudm@hyeyoo>
Date: Mon, 22 Dec 2025 20:14:01 +0900
From: Harry Yoo <harry.yoo@...cle.com>
To: Suren Baghdasaryan <surenb@...gle.com>
Cc: akpm@...ux-foundation.org, vbabka@...e.cz, andreyknvl@...il.com,
        cl@...ux.com, dvyukov@...gle.com, glider@...gle.com,
        hannes@...xchg.org, linux-mm@...ck.org, mhocko@...nel.org,
        muchun.song@...ux.dev, rientjes@...gle.com, roman.gushchin@...ux.dev,
        ryabinin.a.a@...il.com, shakeel.butt@...ux.dev,
        vincenzo.frascino@....com, yeoreum.yun@....com, tytso@....edu,
        adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH V3 7/7] mm/slab: place slabobj_ext metadata in unused
 space within s->size

On Tue, Oct 28, 2025 at 08:19:59PM -0700, Suren Baghdasaryan wrote:
> On Mon, Oct 27, 2025 at 5:29 AM Harry Yoo <harry.yoo@...cle.com> 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) + s->red_left_zone +
> >                      (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 2M directories on xfs):
> >   Slab:            6693844 kB
> >   SReclaimable:    6016332 kB
> >   SUnreclaim:       677512 kB
> >
> > After patch (creating 2M directories on xfs):
> >   Slab:            6697572 kB
> >   SReclaimable:    6034744 kB
> >   SUnreclaim:       662828 kB (-14.3 MiB)
> >
> > Enjoy the memory savings!
> >
> > Suggested-by: Vlastimil Babka <vbabka@...e.cz>
> > Signed-off-by: Harry Yoo <harry.yoo@...cle.com>
> > ---
> > @@ -2250,7 +2293,8 @@ static inline void free_slab_obj_exts(struct slab *slab)
> >         if (!obj_exts)
> >                 return;
> >
> > -       if (obj_exts_in_slab(slab->slab_cache, slab)) {
> > +       if (obj_exts_in_slab(slab->slab_cache, slab) ||
> > +                       obj_exts_in_object(slab->slab_cache)) {
> 

Hi Suren, thanks for the comment.
I should have replied earlier, sorry.
 
> I think you need a check for obj_exts_in_object() inside
> alloc_slab_obj_exts() to avoid allocating the vector.

But slab_obj_exts() check before alloc_slab_obj_exts() should have
returned nonzero if obj_exts_in_object() returns true?

> >                 slab->obj_exts = 0;
> >                 return;
> >         }

-- 
Cheers,
Harry / Hyeonggon