[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.23.453.2011181153390.1618743@chino.kir.corp.google.com>
Date: Wed, 18 Nov 2020 11:53:46 -0800 (PST)
From: David Rientjes <rientjes@...gle.com>
To: Roman Gushchin <guro@...com>
cc: Vlastimil Babka <vbabka@...e.cz>,
Bharata B Rao <bharata@...ux.ibm.com>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org, cl@...ux.com,
iamjoonsoo.kim@....com, akpm@...ux-foundation.org,
shakeelb@...gle.com, hannes@...xchg.org, aneesh.kumar@...ux.ibm.com
Subject: Re: [RFC PATCH v0] mm/slub: Let number of online CPUs determine the
slub page order
On Wed, 18 Nov 2020, Roman Gushchin wrote:
> On Wed, Nov 18, 2020 at 12:25:38PM +0100, Vlastimil Babka wrote:
> > On 11/18/20 9:27 AM, Bharata B Rao wrote:
> > > The page order of the slab that gets chosen for a given slab
> > > cache depends on the number of objects that can be fit in the
> > > slab while meeting other requirements. We start with a value
> > > of minimum objects based on nr_cpu_ids that is driven by
> > > possible number of CPUs and hence could be higher than the
> > > actual number of CPUs present in the system. This leads to
> > > calculate_order() chosing a page order that is on the higher
> > > side leading to increased slab memory consumption on systems
> > > that have bigger page sizes.
> > >
> > > Hence rely on the number of online CPUs when determining the
> > > mininum objects, thereby increasing the chances of chosing
> > > a lower conservative page order for the slab.
> > >
> > > Signed-off-by: Bharata B Rao <bharata@...ux.ibm.com>
> >
> > Acked-by: Vlastimil Babka <vbabka@...e.cz>
> >
> > Ideally, we would react to hotplug events and update existing caches
> > accordingly. But for that, recalculation of order for existing caches would
> > have to be made safe, while not affecting hot paths. We have removed the
> > sysfs interface with 32a6f409b693 ("mm, slub: remove runtime allocation
> > order changes") as it didn't seem easy and worth the trouble.
> >
> > In case somebody wants to start with a large order right from the boot
> > because they know they will hotplug lots of cpus later, they can use
> > slub_min_objects= boot param to override this heuristic. So in case this
> > change regresses somebody's performance, there's a way around it and thus
> > the risk is low IMHO.
>
> I agree. For the absolute majority of users there will be no difference.
> And there is a good workaround for the rest.
>
> Acked-by: Roman Gushchin <guro@...com>
>
Acked-by: David Rientjes <rientjes@...gle.com>
Powered by blists - more mailing lists