[patch 1/2] slab: rename slab_break_gfp_order to slab_max_order

[patch 1/2] slab: rename slab_break_gfp_order to slab_max_order

[David Rientjes]

slab_break_gfp_order is more appropriately named slab_max_order since it
enforces the maximum order size of slabs as long as a single object will
still fit.

Also rename BREAK_GFP_ORDER_{LO,HI} accordingly.

Signed-off-by: David Rientjes <rientjes@google.com>
---
 mm/slab.c |   10 +++++-----
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/mm/slab.c b/mm/slab.c
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -481,9 +481,9 @@ EXPORT_SYMBOL(slab_buffer_size);
 /*
  * Do not go above this order unless 0 objects fit into the slab.
  */
-#define	BREAK_GFP_ORDER_HI	1
-#define	BREAK_GFP_ORDER_LO	0
-static int slab_break_gfp_order = BREAK_GFP_ORDER_LO;
+#define	SLAB_MAX_ORDER_HI	1
+#define	SLAB_MAX_ORDER_LO	0
+static int slab_max_order = SLAB_MAX_ORDER_LO;
 
 /*
  * Functions for storing/retrieving the cachep and or slab from the page
@@ -1502,7 +1502,7 @@ void __init kmem_cache_init(void)
 	 * page orders on machines with more than 32MB of memory.
 	 */
 	if (totalram_pages > (32 << 20) >> PAGE_SHIFT)
-		slab_break_gfp_order = BREAK_GFP_ORDER_HI;
+		slab_max_order = SLAB_MAX_ORDER_HI;
 
 	/* Bootstrap is tricky, because several objects are allocated
 	 * from caches that do not exist yet:
@@ -2112,7 +2112,7 @@ static size_t calculate_slab_order(struct kmem_cache *cachep,
 		 * Large number of objects is good, but very large slabs are
 		 * currently bad for the gfp()s.
 		 */
-		if (gfporder >= slab_break_gfp_order)
+		if (gfporder >= slab_max_order)
 			break;
 
 		/*

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[patch 2/2] slab: introduce slab_max_order kernel parameter

[David Rientjes]

Introduce new slab_max_order kernel parameter which is the equivalent of
slub_max_order.

For immediate purposes, allows users to override the heuristic that sets
the max order to 1 by default if they have more than 32MB of RAM.  This
may result in page allocation failures if there is substantial
fragmentation.

Another usecase would be to increase the max order for better
performance.

Signed-off-by: David Rientjes <rientjes@google.com>
---
 Documentation/kernel-parameters.txt |    6 ++++++
 mm/slab.c                           |   20 +++++++++++++++++---
 2 files changed, 23 insertions(+), 3 deletions(-)

diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2318,6 +2318,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 
 	slram=		[HW,MTD]
 
+	slab_max_order=	[MM, SLAB]
+			Determines the maximum allowed order for slabs.
+			A high setting may cause OOMs due to memory
+			fragmentation.  Defaults to 1 for systems with
+			more than 32MB of RAM, 0 otherwise.
+
 	slub_debug[=options[,slabs]]	[MM, SLUB]
 			Enabling slub_debug allows one to determine the
 			culprit if slab objects become corrupted. Enabling
diff --git a/mm/slab.c b/mm/slab.c
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -479,11 +479,13 @@ EXPORT_SYMBOL(slab_buffer_size);
 #endif
 
 /*
- * Do not go above this order unless 0 objects fit into the slab.
+ * Do not go above this order unless 0 objects fit into the slab or
+ * overridden on the command line.
  */
 #define	SLAB_MAX_ORDER_HI	1
 #define	SLAB_MAX_ORDER_LO	0
 static int slab_max_order = SLAB_MAX_ORDER_LO;
+static bool slab_max_order_set __initdata;
 
 /*
  * Functions for storing/retrieving the cachep and or slab from the page
@@ -851,6 +853,17 @@ static int __init noaliencache_setup(char *s)
 }
 __setup("noaliencache", noaliencache_setup);
 
+static int __init slab_max_order_setup(char *str)
+{
+	get_option(&str, &slab_max_order);
+	slab_max_order = slab_max_order < 0 ? 0 :
+				min(slab_max_order, MAX_ORDER - 1);
+	slab_max_order_set = true;
+
+	return 1;
+}
+__setup("slab_max_order=", slab_max_order_setup);
+
 #ifdef CONFIG_NUMA
 /*
  * Special reaping functions for NUMA systems called from cache_reap().
@@ -1499,9 +1512,10 @@ void __init kmem_cache_init(void)
 
 	/*
 	 * Fragmentation resistance on low memory - only use bigger
-	 * page orders on machines with more than 32MB of memory.
+	 * page orders on machines with more than 32MB of memory if
+	 * not overridden on the command line.
 	 */
-	if (totalram_pages > (32 << 20) >> PAGE_SHIFT)
+	if (!slab_max_order_set && totalram_pages > (32 << 20) >> PAGE_SHIFT)
 		slab_max_order = SLAB_MAX_ORDER_HI;
 
 	/* Bootstrap is tricky, because several objects are allocated

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [patch 1/2] slab: rename slab_break_gfp_order to slab_max_order

[David Rientjes]

On Tue, 18 Oct 2011, David Rientjes wrote:

> slab_break_gfp_order is more appropriately named slab_max_order since it
> enforces the maximum order size of slabs as long as a single object will
> still fit.
> 
> Also rename BREAK_GFP_ORDER_{LO,HI} accordingly.
> 

Ping on these two patches?  I don't see them in slab/next.

> Signed-off-by: David Rientjes <rientjes@google.com>
> ---
>  mm/slab.c |   10 +++++-----
>  1 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/mm/slab.c b/mm/slab.c
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -481,9 +481,9 @@ EXPORT_SYMBOL(slab_buffer_size);
>  /*
>   * Do not go above this order unless 0 objects fit into the slab.
>   */
> -#define	BREAK_GFP_ORDER_HI	1
> -#define	BREAK_GFP_ORDER_LO	0
> -static int slab_break_gfp_order = BREAK_GFP_ORDER_LO;
> +#define	SLAB_MAX_ORDER_HI	1
> +#define	SLAB_MAX_ORDER_LO	0
> +static int slab_max_order = SLAB_MAX_ORDER_LO;
>  
>  /*
>   * Functions for storing/retrieving the cachep and or slab from the page
> @@ -1502,7 +1502,7 @@ void __init kmem_cache_init(void)
>  	 * page orders on machines with more than 32MB of memory.
>  	 */
>  	if (totalram_pages > (32 << 20) >> PAGE_SHIFT)
> -		slab_break_gfp_order = BREAK_GFP_ORDER_HI;
> +		slab_max_order = SLAB_MAX_ORDER_HI;
>  
>  	/* Bootstrap is tricky, because several objects are allocated
>  	 * from caches that do not exist yet:
> @@ -2112,7 +2112,7 @@ static size_t calculate_slab_order(struct kmem_cache *cachep,
>  		 * Large number of objects is good, but very large slabs are
>  		 * currently bad for the gfp()s.
>  		 */
> -		if (gfporder >= slab_break_gfp_order)
> +		if (gfporder >= slab_max_order)
>  			break;
>  
>  		/*
> 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [patch 1/2] slab: rename slab_break_gfp_order to slab_max_order

[Pekka Enberg]

On Tue, 18 Oct 2011, David Rientjes wrote:
>> slab_break_gfp_order is more appropriately named slab_max_order since it
>> enforces the maximum order size of slabs as long as a single object will
>> still fit.
>>
>> Also rename BREAK_GFP_ORDER_{LO,HI} accordingly.

On Thu, Nov 3, 2011 at 11:40 PM, David Rientjes <rientjes@google.com> wrote:
> Ping on these two patches?  I don't see them in slab/next.

The patches seem reasonable to me. Christoph?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [patch 1/2] slab: rename slab_break_gfp_order to slab_max_order

[Christoph Lameter]

On Wed, 9 Nov 2011, Pekka Enberg wrote:

> The patches seem reasonable to me. Christoph?

Looks good and makes the two allocators to behave similarly.

Acked-by: Christoph Lameter <cl@linux.com>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>