The patch titled
Subject: mm/slub: let number of online CPUs determine the slub page order
has been added to the -mm tree. Its filename is
mm-slub-let-number-of-online-cpus-determine-the-slub-page-order.patch
This patch should soon appear at
https://ozlabs.org/~akpm/mmots/broken-out/mm-slub-let-number-of-online-cpus-determine-the-slub-page-order.patch
and later at
https://ozlabs.org/~akpm/mmotm/broken-out/mm-slub-let-number-of-online-cpus-determine-the-slub-page-order.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Bharata B Rao <bharata@xxxxxxxxxxxxx>
Subject: mm/slub: let number of online CPUs determine the slub page order
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.
Vlastimil:
: 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.
Link: https://lkml.kernel.org/r/20201118082759.1413056-1-bharata@xxxxxxxxxxxxx
Signed-off-by: Bharata B Rao <bharata@xxxxxxxxxxxxx>
Acked-by: Vlastimil Babka <vbabka@xxxxxxx>
Acked-by: Roman Gushchin <guro@xxxxxx>
Acked-by: David Rientjes <rientjes@xxxxxxxxxx>
Cc: Christoph Lameter <cl@xxxxxxxxx>
Cc: Joonsoo Kim <iamjoonsoo.kim@xxxxxxx>
Cc: Shakeel Butt <shakeelb@xxxxxxxxxx>
Cc: Johannes Weiner <hannes@xxxxxxxxxxx>
Cc: Aneesh Kumar K.V <aneesh.kumar@xxxxxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
mm/slub.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/mm/slub.c~mm-slub-let-number-of-online-cpus-determine-the-slub-page-order
+++ a/mm/slub.c
@@ -3431,7 +3431,7 @@ static inline int calculate_order(unsign
*/
min_objects = slub_min_objects;
if (!min_objects)
- min_objects = 4 * (fls(nr_cpu_ids) + 1);
+ min_objects = 4 * (fls(num_online_cpus()) + 1);
max_objects = order_objects(slub_max_order, size);
min_objects = min(min_objects, max_objects);
_
Patches currently in -mm which might be from bharata@xxxxxxxxxxxxx are
mm-slub-let-number-of-online-cpus-determine-the-slub-page-order.patch
