Re: [PATCH 2/4] mm, compaction: more reliably increase direct compaction priority

[Vlastimil Babka]

On 09/23/2016 06:04 AM, Hillf Danton wrote:
>>
>> ----8<----
>> From a7921e57ba1189b9c08fc4879358a908c390e47c Mon Sep 17 00:00:00 2001
>> From: Vlastimil Babka <vbabka@xxxxxxx>
>> Date: Thu, 22 Sep 2016 17:02:37 +0200
>> Subject: [PATCH] mm, page_alloc: pull no_progress_loops update to
>>  should_reclaim_retry()
>>
>> The should_reclaim_retry() makes decisions based on no_progress_loops, so it
>> makes sense to also update the counter there. It will be also consistent with
>> should_compact_retry() and compaction_retries. No functional change.
>>
>> Signed-off-by: Vlastimil Babka <vbabka@xxxxxxx>
>> ---
>>  mm/page_alloc.c | 28 ++++++++++++++--------------
>>  1 file changed, 14 insertions(+), 14 deletions(-)
>>
>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>> index 582820080601..a01359ab3ed6 100644
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -3401,16 +3401,26 @@ bool gfp_pfmemalloc_allowed(gfp_t gfp_mask)
>>  static inline bool
>>  should_reclaim_retry(gfp_t gfp_mask, unsigned order,
>>  		     struct alloc_context *ac, int alloc_flags,
>> -		     bool did_some_progress, int no_progress_loops)
>> +		     bool did_some_progress, int *no_progress_loops)
>>  {
>>  	struct zone *zone;
>>  	struct zoneref *z;
>>
>>  	/*
>> +	 * Costly allocations might have made a progress but this doesn't mean
>> +	 * their order will become available due to high fragmentation so
>> +	 * always increment the no progress counter for them
>> +	 */
>> +	if (did_some_progress && order <= PAGE_ALLOC_COSTLY_ORDER)
>> +		no_progress_loops = 0;
> 
> s/no/*no/
>> +	else
>> +		no_progress_loops++;
> 
> s/no_progress_loops/(*no_progress_loops)/

Crap, thanks. I'm asking our gcc guy about possible warnings for this,
and some past mistake I've seen which would be *no_progress_loops++.
 
> With that feel free to add
> Acked-by: Hillf Danton <hillf.zj@xxxxxxxxxxxxxxx>

Thanks!

----8<----