From: Harry Yoo <harry.yoo@oracle.com>
To: Suren Baghdasaryan <surenb@google.com>
Cc: akpm@linux-foundation.org, vbabka@suse.cz, andreyknvl@gmail.com,
cl@linux.com, dvyukov@google.com, glider@google.com,
hannes@cmpxchg.org, linux-mm@kvack.org, mhocko@kernel.org,
muchun.song@linux.dev, rientjes@google.com,
roman.gushchin@linux.dev, ryabinin.a.a@gmail.com,
shakeel.butt@linux.dev, vincenzo.frascino@arm.com,
yeoreum.yun@arm.com, tytso@mit.edu, adilger.kernel@dilger.ca,
linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH V3 3/7] mm/slab: abstract slabobj_ext access via new slab_obj_ext() helper
Date: Thu, 30 Oct 2025 10:26:27 +0900 [thread overview]
Message-ID: <aQK-wyE-h1bvaNOq@hyeyoo> (raw)
In-Reply-To: <CAJuCfpGFPuoUceB7SvAJPtVvzOOCzqS50yCcjbuMxV2a0e0KWA@mail.gmail.com>
On Wed, Oct 29, 2025 at 08:24:35AM -0700, Suren Baghdasaryan wrote:
> On Wed, Oct 29, 2025 at 1:49 AM Harry Yoo <harry.yoo@oracle.com> wrote:
> >
> > On Tue, Oct 28, 2025 at 10:55:39AM -0700, Suren Baghdasaryan wrote:
> > > On Mon, Oct 27, 2025 at 5:29 AM Harry Yoo <harry.yoo@oracle.com> wrote:
> > > >
> > > > Currently, the slab allocator assumes that slab->obj_exts is a pointer
> > > > to an array of struct slabobj_ext objects. However, to support storage
> > > > methods where struct slabobj_ext is embedded within objects, the slab
> > > > allocator should not make this assumption. Instead of directly
> > > > dereferencing the slabobj_exts array, abstract access to
> > > > struct slabobj_ext via helper functions.
> > > >
> > > > Introduce a new API slabobj_ext metadata access:
> > > >
> > > > slab_obj_ext(slab, obj_exts, index) - returns the pointer to
> > > > struct slabobj_ext element at the given index.
> > > >
> > > > Directly dereferencing the return value of slab_obj_exts() is no longer
> > > > allowed. Instead, slab_obj_ext() must always be used to access
> > > > individual struct slabobj_ext objects.
> > >
> > > If direct access to the vector is not allowed, it would be better to
> > > eliminate slab_obj_exts() function completely and use the new
> > > slab_obj_ext() instead. I think that's possible. We might need an
> > > additional `bool is_slab_obj_exts()` helper for an early check before
> > > we calculate the object index but that's quite easy.
> >
> > Good point, but that way we cannot avoid reading slab->obj_exts
> > multiple times when we access slabobj_ext of multiple objects
> > as it's accessed via READ_ONCE().
>
> True. I think we use slab->obj_exts to loop over its elements only in
> two places: __memcg_slab_post_alloc_hook() and
> __memcg_slab_free_hook(). I guess we could implement some kind of
> slab_objext_foreach() construct to loop over all elements of
> slab->obj_exts?
Not sure if that would help here. In __memcg_slab_free_hook() we want to
iterate only some of (not all of) elements from the same slab
(we know they're from the same slab as we build detached freelist and
sort the array) and so we read slab->obj_exts only once.
In __memcg_slab_post_alloc_hook() we don't know if the objects are from
the same slab, so we read slab->obj_exts multiple times and charge them.
I think we need to either 1) remove slab_obj_exts() and
then introduce is_slab_obj_exts() and see if it has impact on
performance, or 2) keep it as-is.
Thanks!
--
Cheers,
Harry / Hyeonggon
next prev parent reply other threads:[~2025-10-30 1:27 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-27 12:28 [RFC PATCH V3 0/7] mm/slab: reduce slab accounting memory overhead by allocating slabobj_ext metadata within unused slab space Harry Yoo
2025-10-27 12:28 ` [RFC PATCH V3 1/7] mm/slab: allow specifying freepointer offset when using constructor Harry Yoo
2025-10-28 17:43 ` Suren Baghdasaryan
2025-10-29 7:10 ` Harry Yoo
2025-10-30 14:35 ` Vlastimil Babka
2025-10-27 12:28 ` [RFC PATCH V3 2/7] ext4: specify the free pointer offset for ext4_inode_cache Harry Yoo
2025-10-28 17:22 ` Suren Baghdasaryan
2025-10-28 17:25 ` Suren Baghdasaryan
2025-10-27 12:28 ` [RFC PATCH V3 3/7] mm/slab: abstract slabobj_ext access via new slab_obj_ext() helper Harry Yoo
2025-10-28 17:55 ` Suren Baghdasaryan
2025-10-29 8:49 ` Harry Yoo
2025-10-29 15:24 ` Suren Baghdasaryan
2025-10-30 1:26 ` Harry Yoo [this message]
2025-10-30 5:03 ` Suren Baghdasaryan
2025-10-27 12:28 ` [RFC PATCH V3 4/7] mm/slab: use stride to access slabobj_ext Harry Yoo
2025-10-28 20:10 ` Suren Baghdasaryan
2025-10-27 12:28 ` [RFC PATCH V3 5/7] mm/memcontrol,alloc_tag: handle slabobj_ext access under KASAN poison Harry Yoo
2025-10-28 23:03 ` Suren Baghdasaryan
2025-10-29 8:06 ` Harry Yoo
2025-10-29 15:28 ` Suren Baghdasaryan
2025-10-27 12:28 ` [RFC PATCH V3 6/7] mm/slab: save memory by allocating slabobj_ext array from leftover Harry Yoo
2025-10-29 3:07 ` Suren Baghdasaryan
2025-10-29 7:59 ` Harry Yoo
2025-10-29 18:37 ` Suren Baghdasaryan
2025-10-30 0:40 ` Harry Yoo
2025-10-30 16:33 ` Vlastimil Babka
2025-10-29 18:45 ` Andrey Ryabinin
2025-10-30 1:11 ` Harry Yoo
2025-10-27 12:28 ` [RFC PATCH V3 7/7] mm/slab: place slabobj_ext metadata in unused space within s->size Harry Yoo
2025-10-29 3:19 ` Suren Baghdasaryan
2025-10-29 18:19 ` Andrey Ryabinin
2025-10-30 0:51 ` Harry Yoo
2025-10-30 12:41 ` Yeoreum Yun
2025-10-30 16:39 ` [RFC PATCH V3 0/7] mm/slab: reduce slab accounting memory overhead by allocating slabobj_ext metadata within unused slab space Vlastimil Babka
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=aQK-wyE-h1bvaNOq@hyeyoo \
--to=harry.yoo@oracle.com \
--cc=adilger.kernel@dilger.ca \
--cc=akpm@linux-foundation.org \
--cc=andreyknvl@gmail.com \
--cc=cl@linux.com \
--cc=dvyukov@google.com \
--cc=glider@google.com \
--cc=hannes@cmpxchg.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=muchun.song@linux.dev \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=ryabinin.a.a@gmail.com \
--cc=shakeel.butt@linux.dev \
--cc=surenb@google.com \
--cc=tytso@mit.edu \
--cc=vbabka@suse.cz \
--cc=vincenzo.frascino@arm.com \
--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;
as well as URLs for NNTP newsgroup(s).