Re: SLUB: Reduce antifrag max order (fwd)

Re: SLUB: Reduce antifrag max order (fwd)

[Mel Gorman]

Sorry for resend, I didn't add Andy to the cc as intended.

On Sat, 5 May 2007, Christoph Lameter wrote:

> My test systems fails to obtain order 4 allocs after prolonged use.
> So the Antifragmentation patches are unable to guarantee order 4
> blocks after a while (straight compile, edit load).
>

Anti-frag still depends on reclaim to take place and I imagine you have not 
altered min_free_kbytes to keep pages free. Also, I don't think kswapd is 
currently making any effort to keep blocks free at a known desired order 
although I'm cc'ing Andy Whitcroft to confirm. As the kernel gives up easily 
when order > PAGE_ALLOC_COSTLY_ORDER, prehaps you should be using 
PAGE_ALLOC_COSTLY_ORDER instead of DEFAULT_ANTIFRAG_MAX_ORDER for SLUB.

> Reduce the the max order if antifrag measures are detected to 3.
> 
> Signed-off-by: Christoph Lameter <clameter@sgi.com>
> 
> ---
> mm/slub.c |    2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Index: slub/mm/slub.c
> ===================================================================
> --- slub.orig/mm/slub.c	2007-05-05 09:19:32.000000000 -0700
> +++ slub/mm/slub.c	2007-05-05 09:22:00.000000000 -0700
> @@ -129,7 +129,7 @@
>  * If antifragmentation methods are in effect then increase the
>  * slab sizes to increase performance
>  */
> -#define DEFAULT_ANTIFRAG_MAX_ORDER 4
> +#define DEFAULT_ANTIFRAG_MAX_ORDER 3
> #define DEFAULT_ANTIFRAG_MIN_OBJECTS 16
> 
> /*
>

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: SLUB: Reduce antifrag max order (fwd)

[Andy Whitcroft]

Mel Gorman wrote:
> Sorry for resend, I didn't add Andy to the cc as intended.
> 
> On Sat, 5 May 2007, Christoph Lameter wrote:
> 
>> My test systems fails to obtain order 4 allocs after prolonged use.
>> So the Antifragmentation patches are unable to guarantee order 4
>> blocks after a while (straight compile, edit load).
>>
> 
> Anti-frag still depends on reclaim to take place and I imagine you have
> not altered min_free_kbytes to keep pages free. Also, I don't think
> kswapd is currently making any effort to keep blocks free at a known
> desired order although I'm cc'ing Andy Whitcroft to confirm. As the
> kernel gives up easily when order > PAGE_ALLOC_COSTLY_ORDER, prehaps you
> should be using PAGE_ALLOC_COSTLY_ORDER instead of
> DEFAULT_ANTIFRAG_MAX_ORDER for SLUB.

kswapd only reactively uses orders above 0.  If allocations are pushing
below the high water marks those will trigger kswapd to reclaim at their
highest order.  No attempt overall is made to keep "some" higher order
pages free.  That is anticipated, but not yet tested.

>> Reduce the the max order if antifrag measures are detected to 3.

As Mel indicates you are probally best staying at or below
PAGE_ALLOC_COSTLY_ORDER and indeed that is probabally what the 3
represents below; the "highest easily allocatable order".  If so it very
likely should be:

#define DEFAULT_ANTIFRAG_MAX_ORDER PAGE_ALLOC_COSTLY_ORDER

<snip>

-apw

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: SLUB: Reduce antifrag max order (fwd)

[Nick Piggin]

Andy Whitcroft wrote:
> Mel Gorman wrote:
> 
>>Sorry for resend, I didn't add Andy to the cc as intended.
>>
>>On Sat, 5 May 2007, Christoph Lameter wrote:
>>
>>
>>>My test systems fails to obtain order 4 allocs after prolonged use.
>>>So the Antifragmentation patches are unable to guarantee order 4
>>>blocks after a while (straight compile, edit load).
>>>
>>
>>Anti-frag still depends on reclaim to take place and I imagine you have
>>not altered min_free_kbytes to keep pages free. Also, I don't think
>>kswapd is currently making any effort to keep blocks free at a known
>>desired order although I'm cc'ing Andy Whitcroft to confirm. As the
>>kernel gives up easily when order > PAGE_ALLOC_COSTLY_ORDER, prehaps you
>>should be using PAGE_ALLOC_COSTLY_ORDER instead of
>>DEFAULT_ANTIFRAG_MAX_ORDER for SLUB.
> 
> 
> kswapd only reactively uses orders above 0.  If allocations are pushing
> below the high water marks those will trigger kswapd to reclaim at their
> highest order.  No attempt overall is made to keep "some" higher order
> pages free.

It does try, if you have a look at zone_watermark_ok. But it doesn't
check for pages of a higher order than are being allocated (ie. so
an order-0 alloc could split the last free order-3 page).

This is intentional, because if your workload isn't doing any higher
order allocations, it should not be trying to keep any free.

-- 
SUSE Labs, Novell Inc.

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>