Re: [PATCH -mm] slub: document setting min order with debug_guardpage_minorder > 0

[Rafael J. Wysocki]

On Monday, December 12, 2011, Stanislaw Gruszka wrote:
> Signed-off-by: Stanislaw Gruszka <sgruszka@xxxxxxxxxx>
> ---
> English is hard (definitely harder than C language :-), so please correct
> me, if I wrote something wrong.
> 
>  Documentation/ABI/testing/sysfs-kernel-slab |    4 +++-
>  Documentation/vm/slub.txt                   |    4 +++-
>  2 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/ABI/testing/sysfs-kernel-slab b/Documentation/ABI/testing/sysfs-kernel-slab
> index 8b093f8..d84ca80 100644
> --- a/Documentation/ABI/testing/sysfs-kernel-slab
> +++ b/Documentation/ABI/testing/sysfs-kernel-slab
> @@ -345,7 +345,9 @@ Description:
>  		allocated.  It is writable and can be changed to increase the
>  		number of objects per slab.  If a slab cannot be allocated
>  		because of fragmentation, SLUB will retry with the minimum order
> -		possible depending on its characteristics.
> +		possible depending on its characteristics. 

Added trailing whitespace (please remove).

> +		When debug_guardpage_minorder > 0 parameter is specified, the
> +		minimum possible order is used and cannot be changed.

Well, I'm not sure what you wanted to say, actually?  How does one change
debug_guardpage_minorder (or specify it), for example?  Is it a kernel
command-line switch?

Also I'm not sure what "cannot be changed" is supposed to mean.  Does it
mean that /sys/cache/slab/cache/order has no effect in that case?

>  
>  What:		/sys/kernel/slab/cache/order_fallback
>  Date:		April 2008
> diff --git a/Documentation/vm/slub.txt b/Documentation/vm/slub.txt
> index f464f47..dbf02ad 100644
> --- a/Documentation/vm/slub.txt
> +++ b/Documentation/vm/slub.txt
> @@ -131,7 +131,9 @@ slub_min_objects.
>  slub_max_order specified the order at which slub_min_objects should no
>  longer be checked. This is useful to avoid SLUB trying to generate
>  super large order pages to fit slub_min_objects of a slab cache with
> -large object sizes into one high order page.
> +large object sizes into one high order page. Setting parameter
> +debug_guardpage_minorder > 0 forces setting slub_max_order to 0, what
> +cause minimum possible order of slabs allocation.
>  
>  SLUB Debug output
>  -----------------
> 

Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/