From: Harry Yoo <harry.yoo@oracle.com>
To: Yeoreum Yun <yeoreum.yun@arm.com>
Cc: Vlastimil Babka <vbabka@suse.cz>,
David Rientjes <rientjes@google.com>,
Christoph Lameter <cl@linux.com>,
Andrew Morton <akpm@linux-foundation.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@kernel.org>,
Roman Gushchin <roman.gushchin@linux.dev>,
Shakeel Butt <shakeel.butt@linux.dev>,
Muchun Song <muchun.song@linux.dev>,
Suren Baghdasaryan <surenb@google.com>,
Kent Overstreet <kent.overstreet@linux.dev>,
Andrey Ryabinin <ryabinin.a.a@gmail.com>,
Alexander Potapenko <glider@google.com>,
Andrey Konovalov <andreyknvl@gmail.com>,
Dmitry Vyukov <dvyukov@google.com>,
Vincenzo Frascino <vincenzo.frascino@arm.com>,
linux-mm@kvack.org
Subject: Re: [RFC PATCH] mm/slab: save memory by allocating slabobj_ext array from leftover
Date: Sat, 14 Jun 2025 02:58:19 +0900 [thread overview]
Message-ID: <aExmu956uIkVtrFW@hyeyoo> (raw)
In-Reply-To: <aEwOnmW21Ag4oedx@e129823.arm.com>
On Fri, Jun 13, 2025 at 12:42:22PM +0100, Yeoreum Yun wrote:
> Hi Harry,
>
> [...]
Hi Yeoreum,
> > Allocate slabobj_exts array from this unused space instead of using
> > kcalloc(), when it is large enough.
> >
> > Enjoy the memory savings!
> >
> > [ MEMCG=y, MEM_ALLOC_PROFILING=y ]
> >
> > Before patch (run updatedb):
> > Slab: 5815196 kB
> > SReclaimable: 5042824 kB
> > SUnreclaim: 772372 kB
> >
> > After patch (run updatedb):
> > Slab: 5748664 kB
> > SReclaimable: 5041608 kB
> > SUnreclaim: 707084 kB (-63.75 MiB)
> >
> > [ MEMCG=y, MEM_ALLOC_PROFILING=n ]
> >
> > Before patch (run updatedb):
> > Slab: 5637764 kB
> > SReclaimable: 5042428 kB
> > SUnreclaim: 595284 kB
> >
> > After patch (run updatedb):
> > Slab: 5598992 kB
> > SReclaimable: 5042248 kB
> > SUnreclaim: 560396 kB (-34.07 MiB)
> >
> > This saves from hundreds of KiBs up to several tens of MiBs of memory
> > on my machine, depending on the config and slab memory usage.
> >
> > Enjoy the memory savings!
>
> Awesome :)
Thanks :)
> [...]
> > #ifdef CONFIG_SLUB_DEBUG
> > static unsigned long object_map[BITS_TO_LONGS(MAX_OBJS_PER_PAGE)];
> > static DEFINE_SPINLOCK(object_map_lock);
> > @@ -1307,7 +1350,15 @@ slab_pad_check(struct kmem_cache *s, struct slab *slab)
> > start = slab_address(slab);
> > length = slab_size(slab);
> > end = start + length;
> > - remainder = length % s->size;
> > +
> > + if (can_alloc_obj_exts_from_leftover(s, slab)) {
> > + remainder = length;
> > + remainder -= obj_exts_offset(s, slab);
> > + remainder -= obj_exts_size(slab);
> > + } else {
> > + remainder = length % s->size;
> > + }
> > +
> > if (!remainder)
> > return;
> >
> > @@ -2049,6 +2100,21 @@ static noinline void free_slab_obj_exts(struct slab *slab)
> > slab->obj_exts = 0;
> > }
>
> What concerns me about this patch is the case where !memcg_kmem_online() and
> MEM_ALLOC_PROFILING is not used.
> With this patch, obj_ext can still be created even in that situation,
> and as a result, if data is overwritten in the region previously padded with
> POISON_INUSE (before the patch), slab_pad_check() may no longer catch it
That's a valid point.
I think allocating the array from the leftover space can be deferred
until either MEMCG or MEM_ALLOC_PROFILING actually requests it.
> If this's ignorable, feel free toadd :
>
> Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
That means the implementation will change a bit, so it's better to drop
the R-b tag as the new change may invalidate "Looks good to me" state.
I'll Cc you in the next version—please take a look and review the
updated version.
Thanks for reviewing!
--
Cheers,
Harry / Hyeonggon
next prev parent reply other threads:[~2025-06-13 17:58 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-13 6:33 [RFC PATCH] mm/slab: save memory by allocating slabobj_ext array from leftover Harry Yoo
2025-06-13 7:11 ` Harry Yoo
2025-06-13 11:42 ` Yeoreum Yun
2025-06-13 17:58 ` Harry Yoo [this message]
2025-06-13 16:04 ` Christoph Lameter (Ampere)
2025-06-13 17:47 ` Harry Yoo
2025-06-16 11:00 ` Harry Yoo
2025-06-19 7:56 ` Vlastimil Babka
2025-08-05 11:57 ` Harry Yoo
2025-08-08 14:44 ` Vlastimil Babka
2025-08-27 11:40 ` 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=aExmu956uIkVtrFW@hyeyoo \
--to=harry.yoo@oracle.com \
--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=kent.overstreet@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=ryabinin.a.a@gmail.com \
--cc=shakeel.butt@linux.dev \
--cc=surenb@google.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.