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 0/2] Only allow SLAB_OBJ_EXT_IN_OBJ for unmergeable caches
Date: Tue, 27 Jan 2026 19:31:49 +0900 [thread overview]
Message-ID: <20260127103151.21883-1-harry.yoo@oracle.com> (raw)
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.
So let's take a conservative approach and restrict SLAB_OBJ_EXT_IN_OBJ
to caches that are already unmergeable for other reasons.
Ideally this should be part of the slab/for-7.0/obj_metadata branch,
but due to a conflict with slab/for-7.0/sheaves, I based it on
slab/for-next (be36abd97e52).
Patch 1 factors out mergeability logic to slab_args_unmergeable().
This is used to determine mergeability before the cache is created.
Patch 2 uses the new function to allow SLAB_OBJ_EXT_IN_OBJ
only when merging is not allowed for other reasons.
Harry Yoo (2):
mm/slab: factor out slab_args_unmergeable()
mm/slab: only allow SLAB_OBJ_EXT_IN_OBJ for unmergeable caches
mm/slab.h | 1 +
mm/slab_common.c | 27 +++++++++++++++++----------
mm/slub.c | 3 ++-
3 files changed, 20 insertions(+), 11 deletions(-)
--
2.43.0
next 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 Harry Yoo [this message]
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 ` [PATCH V1 2/2] mm/slab: only allow SLAB_OBJ_EXT_IN_OBJ for unmergeable caches Harry Yoo
2026-02-03 11:56 ` 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-1-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