[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <005b01d2154f$8d38b830$a7aa2890$@alibaba-inc.com>
Date: Fri, 23 Sep 2016 12:04:15 +0800
From: "Hillf Danton" <hillf.zj@...baba-inc.com>
To: "'Vlastimil Babka'" <vbabka@...e.cz>,
"'Michal Hocko'" <mhocko@...nel.org>
Cc: "'Andrew Morton'" <akpm@...ux-foundation.org>,
"'Arkadiusz Miskiewicz'" <a.miskiewicz@...il.com>,
"'Ralf-Peter Rohbeck'" <Ralf-Peter.Rohbeck@...ntum.com>,
"'Olaf Hering'" <olaf@...fle.de>, <linux-kernel@...r.kernel.org>,
"'Linus Torvalds'" <torvalds@...ux-foundation.org>,
<linux-mm@...ck.org>, "'Mel Gorman'" <mgorman@...hsingularity.net>,
"'Joonsoo Kim'" <iamjoonsoo.kim@....com>,
"'David Rientjes'" <rientjes@...gle.com>,
"'Rik van Riel'" <riel@...hat.com>
Subject: Re: [PATCH 2/4] mm, compaction: more reliably increase direct compaction priority
>
> ----8<----
> From a7921e57ba1189b9c08fc4879358a908c390e47c Mon Sep 17 00:00:00 2001
> From: Vlastimil Babka <vbabka@...e.cz>
> 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@...e.cz>
> ---
> 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)/
With that feel free to add
Acked-by: Hillf Danton <hillf.zj@...baba-inc.com>
> +
> + /*
> * Make sure we converge to OOM if we cannot make any progress
> * several times in the row.
> */
> - if (no_progress_loops > MAX_RECLAIM_RETRIES)
> + if (*no_progress_loops > MAX_RECLAIM_RETRIES)
> return false;
>
> /*
> @@ -3425,7 +3435,7 @@ should_reclaim_retry(gfp_t gfp_mask, unsigned order,
> unsigned long reclaimable;
>
> available = reclaimable = zone_reclaimable_pages(zone);
> - available -= DIV_ROUND_UP(no_progress_loops * available,
> + available -= DIV_ROUND_UP((*no_progress_loops) * available,
> MAX_RECLAIM_RETRIES);
> available += zone_page_state_snapshot(zone, NR_FREE_PAGES);
>
> @@ -3641,18 +3651,8 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
> if (order > PAGE_ALLOC_COSTLY_ORDER && !(gfp_mask & __GFP_REPEAT))
> goto nopage;
>
> - /*
> - * 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;
> - else
> - no_progress_loops++;
> -
> if (should_reclaim_retry(gfp_mask, order, ac, alloc_flags,
> - did_some_progress > 0, no_progress_loops))
> + did_some_progress > 0, &no_progress_loops))
> goto retry;
>
> /*
> --
> 2.10.0
Powered by blists - more mailing lists