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
> 
> Using my super powers it took me all of three minutes.
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/old-2.6-bkcvs.git
> 
> Do `git log > foo', and search foo for GFP_REPEAT.
> 
> A couple of interesting ones are:
> 

Ok, so __GFP_REPEAT was used to replace the open-coding of retry loops by 
putting that logic into the page allocator, and that logic was 
subsequently changed to tie the bit to how many pages were reclaimed and 
retry iff we haven't reclaimed the number of pages needed (in my patch, 
that would be a single page).

It also shows that the page allocator has infinitely looped for 
allocations under PAGE_ALLOC_COSTLY_ORDER since your patch from over seven 
years ago.

So, given the fact that the PAGE_ALLOC_COSTLY_ORDER logic has existed 
since the same time, the semantics of __GFP_REPEAT have changed and are 
often misrepresented, and we don't even invoke the __GFP_REPEAT logic for 
any of the allocations in my patch since they are oom killable, I think my 
patch should be merged.

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