linux-kernel - Re: [PATCH V6 9/9] 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <fecd4166-618d-4d69-be02-d9b3e8f0f271@suse.cz>
Date: Tue, 13 Jan 2026 13:50:31 +0100
From: Vlastimil Babka <vbabka@...e.cz>
To: Harry Yoo <harry.yoo@...cle.com>, akpm@...ux-foundation.org
Cc: andreyknvl@...il.com, cl@...two.org, 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,
 surenb@...gle.com, vincenzo.frascino@....com, yeoreum.yun@....com,
 tytso@....edu, adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org,
 linux-kernel@...r.kernel.org, cgroups@...r.kernel.org, hao.li@...ux.dev
Subject: Re: [PATCH V6 9/9] mm/slab: place slabobj_ext metadata in unused
 space within s->size

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@...e.cz>
> Signed-off-by: Harry Yoo <harry.yoo@...cle.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);
 }
 
 static unsigned int obj_exts_offset_in_object(struct kmem_cache *s)