From: Harry Yoo <harry.yoo@oracle.com>
To: Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@suse.cz>
Cc: Christoph Lameter <cl@gentwo.org>,
David Rientjes <rientjes@google.com>,
Roman Gushchin <roman.gushchin@linux.dev>,
Muchun Song <muchun.song@linux.dev>,
Shakeel Butt <shakeel.butt@linux.dev>,
Michal Hocko <mhocko@kernel.org>,
Yeoreum Yun <yeoreum.yun@arm.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Suren Baghdasaryan <surenb@google.com>,
Harry Yoo <harry.yoo@oracle.com>, Hai Li <hao.li@linux.dev>,
linux-mm@kvack.org
Subject: [PATCH V1 2/2] mm/slab: only allow SLAB_OBJ_EXT_IN_OBJ for unmergeable caches
Date: Tue, 27 Jan 2026 19:31:51 +0900 [thread overview]
Message-ID: <20260127103151.21883-3-harry.yoo@oracle.com> (raw)
In-Reply-To: <20260127103151.21883-1-harry.yoo@oracle.com>
While SLAB_OBJ_EXT_IN_OBJ allows to reduce memory overhead to account
slab objects, it prevents slab merging because merging can change
the metadata layout.
As pointed out Vlastimil Babka, disabling merging solely for this memory
optimization may not be a net win, because disabling slab merging tends
to increase overall memory usage.
Restrict SLAB_OBJ_EXT_IN_OBJ to caches that are already unmergeable for
other reasons (e.g., those with constructors or SLAB_TYPESAFE_BY_RCU).
Suggested-by: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Harry Yoo <harry.yoo@oracle.com>
---
mm/slab.h | 1 +
mm/slab_common.c | 3 +--
mm/slub.c | 3 ++-
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/mm/slab.h b/mm/slab.h
index 8593c506cbf1..a5c4f981ee8b 100644
--- a/mm/slab.h
+++ b/mm/slab.h
@@ -388,6 +388,7 @@ extern void create_boot_cache(struct kmem_cache *, const char *name,
unsigned int useroffset, unsigned int usersize);
int slab_unmergeable(struct kmem_cache *s);
+bool slab_args_unmergeable(struct kmem_cache_args *args, slab_flags_t flags);
slab_flags_t kmem_cache_flags(slab_flags_t flags, const char *name);
diff --git a/mm/slab_common.c b/mm/slab_common.c
index 904414c3ebb8..d5a70a831a2a 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -174,8 +174,7 @@ int slab_unmergeable(struct kmem_cache *s)
return 0;
}
-static bool slab_args_unmergeable(struct kmem_cache_args *args,
- slab_flags_t flags)
+bool slab_args_unmergeable(struct kmem_cache_args *args, slab_flags_t flags)
{
if (slab_nomerge)
return true;
diff --git a/mm/slub.c b/mm/slub.c
index ae9af184a18b..0581847e7dac 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -7676,7 +7676,8 @@ static int calculate_sizes(struct kmem_cache_args *args, struct kmem_cache *s)
*/
aligned_size = ALIGN(size, s->align);
#if defined(CONFIG_SLAB_OBJ_EXT) && defined(CONFIG_64BIT)
- if (aligned_size - size >= sizeof(struct slabobj_ext))
+ if (slab_args_unmergeable(args, s->flags) &&
+ (aligned_size - size >= sizeof(struct slabobj_ext)))
s->flags |= SLAB_OBJ_EXT_IN_OBJ;
#endif
size = aligned_size;
--
2.43.0
next prev parent reply other threads:[~2026-01-27 10:32 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-27 10:31 [PATCH V1 0/2] Only " Harry Yoo
2026-01-27 10:31 ` [PATCH V1 1/2] mm/slab: factor out slab_args_unmergeable() Harry Yoo
2026-01-27 16:35 ` Vlastimil Babka
2026-01-27 16:42 ` Harry Yoo
2026-01-27 16:49 ` Vlastimil Babka
2026-01-27 10:31 ` Harry Yoo [this message]
2026-02-03 11:56 ` [PATCH V1 2/2] mm/slab: only allow SLAB_OBJ_EXT_IN_OBJ for unmergeable caches Hao Li
2026-02-03 12:32 ` Harry Yoo
2026-02-04 0:45 ` Hao Li
2026-02-05 5:13 ` Harry Yoo
2026-02-05 6:27 ` Hao Li
2026-01-27 17:06 ` [PATCH V1 0/2] Only " Vlastimil Babka
2026-01-27 18:21 ` Johannes Weiner
2026-01-28 3:09 ` To enable, or not to enable slab merging? That is the question (was: Re: [PATCH V1 0/2] Only allow SLAB_OBJ_EXT_IN_OBJ for unmergeable caches) Harry Yoo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260127103151.21883-3-harry.yoo@oracle.com \
--to=harry.yoo@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=cl@gentwo.org \
--cc=hannes@cmpxchg.org \
--cc=hao.li@linux.dev \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=muchun.song@linux.dev \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=shakeel.butt@linux.dev \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
--cc=yeoreum.yun@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox