[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <CTODJTSTD9WR.82GVFKOIDIUK@imme>
Date: Wed, 28 Jun 2023 17:05:08 +0200
From: "Julian Pidancet" <julian.pidancet@...cle.com>
To: "David Rientjes" <rientjes@...gle.com>
Cc: "Christoph Lameter" <cl@...ux.com>,
"Pekka Enberg" <penberg@...nel.org>,
"Joonsoo Kim" <iamjoonsoo.kim@....com>,
"Andrew Morton" <akpm@...ux-foundation.org>,
"Vlastimil Babka" <vbabka@...e.cz>,
"Roman Gushchin" <roman.gushchin@...ux.dev>,
"Hyeonggon Yoo" <42.hyeyoo@...il.com>, <linux-mm@...ck.org>,
"Jonathan Corbet" <corbet@....net>, <linux-doc@...r.kernel.org>,
<linux-kernel@...r.kernel.org>,
"Matthew Wilcox" <willy@...radead.org>,
"Kees Cook" <keescook@...omium.org>,
"Rafael Aquini" <aquini@...hat.com>
Subject: Re: [PATCH] mm/slub: disable slab merging in the default
configuration
On Tue Jun 27, 2023 at 21:32, David Rientjes wrote:
> On Tue, 27 Jun 2023, Julian Pidancet wrote:
>
> > Make CONFIG_SLAB_MERGE_DEFAULT default to n unless CONFIG_SLUB_TINY is
> > enabled. Benefits of slab merging is limited on systems that are not
> > memory constrained: the overhead is negligible and evidence of its
> > effect on cache hotness is hard to come by.
> >
>
> I don't have an objection to this, I think it makes sense.
>
> When you say overhead here, I assume you're referring to memory footprint?
> Did you happen to have some system-wide numbers for what that looks like
> when running some benchmarks, or even what the slab usage looks like after
> a fresh boot?
>
Thank you David for the quick review. I'll re-run the benchmark and
measure slab usage when the system is under pressure.
Regards,
--
Julian
Download attachment "signature.asc" of type "application/pgp-signature" (266 bytes)
Powered by blists - more mailing lists