On Fri 23-09-16 08:55:33, Vlastimil Babka wrote: [...] > >From 1623d5bd441160569ffad3808aeeec852048e558 Mon Sep 17 00:00:00 2001 > From: Vlastimil Babka <[email protected]> > 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. > > [[email protected]: fix missing pointer dereferences] > Signed-off-by: Vlastimil Babka <[email protected]> > Acked-by: Hillf Danton <[email protected]>
OK, this looks reasonable to me. Could you post both patches in a separate thread please? They shouldn't be really needed to mitigate the pre-mature oom killer issues. Feel free to add Acked-by: Michal Hocko <[email protected]> Thanks! > --- > 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..6039ff40452c 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; > + else > + (*no_progress_loops)++; > + > + /* > * 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 > > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to [email protected]. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: <a href=mailto:"[email protected]";> [email protected] </a> -- Michal Hocko SUSE Labs
