Re: [rfc 3/4] mm, page_alloc: avoid expensive reclaim when compaction may not succeed

[Mike Kravetz <mike.kravetz@oracle.com>]

On 9/5/19 4:22 AM, Vlastimil Babka wrote:
> On 9/5/19 11:00 AM, Michal Hocko wrote:
>> [Ccing Mike for checking on the hugetlb side of this change]
>> On Wed 04-09-19 12:54:22, David Rientjes wrote:
>>> @@ -4458,6 +4458,28 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
>>>  		if (page)
>>>  			goto got_pg;
>>>  
>>> +		 if (order >= pageblock_order && (gfp_mask & __GFP_IO)) {
>>> +			/*
>>> +			 * If allocating entire pageblock(s) and compaction
>>> +			 * failed because all zones are below low watermarks
>>> +			 * or is prohibited because it recently failed at this
>>> +			 * order, fail immediately.
>>> +			 *
>>> +			 * Reclaim is
>>> +			 *  - potentially very expensive because zones are far
>>> +			 *    below their low watermarks or this is part of very
>>> +			 *    bursty high order allocations,
>>> +			 *  - not guaranteed to help because isolate_freepages()
>>> +			 *    may not iterate over freed pages as part of its
>>> +			 *    linear scan, and
>>> +			 *  - unlikely to make entire pageblocks free on its
>>> +			 *    own.
>>> +			 */
>>> +			if (compact_result == COMPACT_SKIPPED ||
>>> +			    compact_result == COMPACT_DEFERRED)
>>> +				goto nopage;
> 
> As I said, I expect this will make hugetlbfs reservations fail
> prematurely - Mike can probably confirm or disprove that.

I don't have a specific test for this.  It is somewhat common for people
to want to allocate "as many hugetlb pages as possible".  Therefore, they
will try to allocate more pages than reasonable for their environment and
take what they can get.  I 'tested' by simply creating some background
activity and then seeing how many hugetlb pages could be allocated.  Of
course, many tries over time in a loop.

This patch did not cause premature allocation failures in my limited testing.
The number of pages which could be allocated with and without patch were
pretty much the same.

Do note that I tested on top of Andrew's tree which contains this series:
http://lkml.kernel.org/r/20190806014744.15446-1-mike.kravetz@oracle.com
Patch 3 in that series causes allocations to fail sooner in the case of
COMPACT_DEFERRED:
http://lkml.kernel.org/r/20190806014744.15446-4-mike.kravetz@oracle.com

hugetlb allocations have the __GFP_RETRY_MAYFAIL flag set.  They are willing
to retry and wait and callers are aware of this.  Even though my limited
testing did not show regressions caused by this patch, I would prefer if the
quick exit did not apply to __GFP_RETRY_MAYFAIL requests.
-- 
Mike Kravetz