Setting slub_max_order to 0 makes slub to use minimum possible
order for slub page.
Pros:
- Less fragmentation of slab objects in slab pages -> less slab
consumption. E.g. on dvd-store test on machine with 256G this
saves us ~3G.
- Potentially faster in high memory fragmentation cases (we don't attempt
to allocate higher-than-necessary-order page).
Cons:
- Potentially slower if higher-order page available in the system
(less __alloc_pages() calls).
- May increase memory waste for kmem_caches of certain size
(e.g. with 1025-byte objects we waste 1022 bytes per 4096 bytes if
slub order is zero. But with slub order 3 and 1025-byte objects
we waste only 993-bytes per 32768 bytes => 124 bytes per 4096)
According to dvd-store test pros of this change is outweigh the cons.
https://jira.sw.ru/browse/PSBM-83199
Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com>
---
mm/slub.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/slub.c b/mm/slub.c
index de39b176c995..1fb70dcb6d82 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -2989,7 +2989,7 @@ EXPORT_SYMBOL(kmem_cache_alloc_bulk);
* take the list_lock.
*/
static int slub_min_order;
-static int slub_max_order = PAGE_ALLOC_COSTLY_ORDER;
+static int slub_max_order;
static int slub_min_objects;
/*
--
2.19.2
_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel
