linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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


  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 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox