Re: [patch] arch: remove __GFP_REPEAT for order-0 allocations

[David Rientjes <rientjes@google.com>]

On Tue, 28 Sep 2010, Andrew Morton wrote:

> > So we can definitely remove __GFP_REPEAT for any order-0 allocation and 
> > it's based on its implementation -- poorly defined as it may be -- and the 
> > inherit design of any sane page allocator that retries such an allocation 
> > if it's going to use reclaim in the first place.
> 
> Why was __GFP_REPEAT used in those callsites?  What were people trying
> to achieve?
> 

I can't predict what they were trying to achieve since the documentation 
varies on the semantics of __GFP_REPEAT, but the actual implementation 
would suggest that we want to ensure that reclaim actually frees memory 
before we fail the allocation, and that was probably done before it was 
decided to implicitly loop already for order-3 and smaller allocations and 
prehaps even predates the oom killer.

With the oom killer, which would be used iff direct reclaim failed for the 
allocs touched in this patch, we can't report how much memory may be freed 
when that killed task exits, so we implicitly loop forever regardless of 
__GFP_REPEAT (and for a reason other than PAGE_ALLOC_COSTLY_ORDER: if the 
oom killer kills or finds a task that has already been killed but yet to 
exit, it automatically retries the allocation waiting for that free memory 
without even looking at should_alloc_retry()).

--
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>