From 13ffab6bbcfeedb9c125d934248ecebe8fdb7bd2 Mon Sep 17 00:00:00 2001 From: Mel Gorman Date: Wed, 11 May 2011 16:29:33 +0100 Subject: mm: slub: Default slub_max_order to 0 To avoid locking and per-cpu overhead, SLUB optimisically uses high-order allocations up to order-3 by default and falls back to lower allocations if they fail. While care is taken that the caller and kswapd take no unusual steps in response to this, there are further consequences like shrinkers who have to free more objects to release any memory. There is anecdotal evidence that significant time is being spent looping in shrinkers with insufficient progress being made (https://lkml.org/lkml/2011/4/28/361) and keeping kswapd awake. SLUB is now the default allocator and some bug reports have been pinned down to SLUB using high orders during operations like copying large amounts of data. SLUBs use of high-orders benefits applications that are sized to memory appropriately but this does not necessarily apply to large file servers or desktops. This patch causes SLUB to use order-0 pages like SLAB does by default. There is further evidence that this keeps kswapd's usage lower (https://lkml.org/lkml/2011/5/10/383). Signed-off-by: Mel Gorman Signed-off-by: franciscofranco --- Documentation/vm/slub.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation/vm') diff --git a/Documentation/vm/slub.txt b/Documentation/vm/slub.txt index b0c6d1bbb..74a8b93ab 100644 --- a/Documentation/vm/slub.txt +++ b/Documentation/vm/slub.txt @@ -117,7 +117,7 @@ can be influenced by kernel parameters: slub_min_objects=x (default 4) slub_min_order=x (default 0) -slub_max_order=x (default 3 (PAGE_ALLOC_COSTLY_ORDER)) +slub_max_order=x (default 0) slub_min_objects allows to specify how many objects must at least fit into one slab in order for the allocation order to be acceptable. -- cgit v1.2.3