Re: [RFC 3/3] mm: use watermak checks for __GFP_REPEAT high order allocations

[David Rientjes <rientjes@google.com>]

On Fri, 20 Nov 2015, Michal Hocko wrote:

> > > @@ -3167,24 +3166,21 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
> > >  
> > >  	/*
> > >  	 * Do not retry high order allocations unless they are __GFP_REPEAT
> > > -	 * and even then do not retry endlessly unless explicitly told so
> > > +	 * unless explicitly told so.
> > >  	 */
> > > -	pages_reclaimed += did_some_progress;
> > > -	if (order > PAGE_ALLOC_COSTLY_ORDER) {
> > > -		if (!(gfp_mask & __GFP_NOFAIL) &&
> > > -		   (!(gfp_mask & __GFP_REPEAT) || pages_reclaimed >= (1<<order)))
> > > -			goto noretry;
> > > -
> > > -		if (did_some_progress)
> > > -			goto retry;
> > > -	}
> > > +	if (order > PAGE_ALLOC_COSTLY_ORDER &&
> > > +			!(gfp_mask & (__GFP_REPEAT|__GFP_NOFAIL)))
> > > +		goto noretry;
> > 
> > Who is allocating order > PAGE_ALLOC_COSTLY_ORDER with __GFP_REPEAT and 
> > would be affected by this change?
> 
> E.g. hugetlb pages. I have tested this in my testing scenario 3.
> 

If that's the only high-order user of __GFP_REPEAT, we might want to 
consider dropping it.  I believe the hugetlb usecase would only be 
relevant in early init (when __GFP_REPEAT shouldn't logically help) and 
when returning surplus pages due to hugetlb overcommit.  Since hugetlb 
overcommit is best effort and we already know that the
pages_reclaimed >= (1<<order) check is ridiculous for order-9 pages, I 
think you could just drop hugetlb's usage of __GFP_REPEAT and nobody would 
notice.

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