From: Michal Hocko <mhocko@kernel.org> To: Vlastimil Babka <vbabka@suse.cz> Cc: Andrew Morton <akpm@linux-foundation.org>, Arkadiusz Miskiewicz <a.miskiewicz@gmail.com>, Ralf-Peter Rohbeck <Ralf-Peter.Rohbeck@quantum.com>, Olaf Hering <olaf@aepfle.de>, linux-kernel@vger.kernel.org, Linus Torvalds <torvalds@linux-foundation.org>, linux-mm@kvack.org, Mel Gorman <mgorman@techsingularity.net>, Joonsoo Kim <iamjoonsoo.kim@lge.com>, David Rientjes <rientjes@google.com>, Rik van Riel <riel@redhat.com> Subject: Re: [PATCH 2/4] mm, compaction: more reliably increase direct compaction priority Date: Thu, 22 Sep 2016 16:52:37 +0200 [thread overview] Message-ID: <20160922145237.GH11875@dhcp22.suse.cz> (raw) In-Reply-To: <20160922140821.GG11875@dhcp22.suse.cz> On Thu 22-09-16 16:08:21, Michal Hocko wrote: > On Thu 22-09-16 14:51:48, Vlastimil Babka wrote: > > >From 465e1bd61b7a6d6901a44f09b1a76514dbc220fa Mon Sep 17 00:00:00 2001 > > From: Vlastimil Babka <vbabka@suse.cz> > > Date: Thu, 22 Sep 2016 13:54:32 +0200 > > Subject: [PATCH] mm, compaction: more reliably increase direct compaction > > priority-fix > > > > When increasing the compaction priority, also reset retries. Otherwise we can > > consume all retries on the lower priorities. > > OK, this is an improvement. I am just thinking that we might want to > pull > if (order && compaction_made_progress(compact_result)) > compaction_retries++; > > into should_compact_retry as well. I've had it there originally because > it was in line with no_progress_loops but now that we have compaction > priorities it would fit into retry logic better. As a plus it would > count only those compaction rounds where we we didn't have to rely on did that should be > the compaction retry logic. What do you think? > > > Suggested-by: Michal Hocko <mhocko@suse.com> > > Signed-off-by: Vlastimil Babka <vbabka@suse.cz> > > Anyway > Acked-by: Michal Hocko <mhocko@suse.com> > > > --- > > mm/page_alloc.c | 13 +++++++------ > > 1 file changed, 7 insertions(+), 6 deletions(-) > > > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > > index f8bed910e3cf..82fdb690ac62 100644 > > --- a/mm/page_alloc.c > > +++ b/mm/page_alloc.c > > @@ -3162,7 +3162,7 @@ static inline bool > > should_compact_retry(struct alloc_context *ac, int order, int alloc_flags, > > enum compact_result compact_result, > > enum compact_priority *compact_priority, > > - int compaction_retries) > > + int *compaction_retries) > > { > > int max_retries = MAX_COMPACT_RETRIES; > > > > @@ -3196,16 +3196,17 @@ should_compact_retry(struct alloc_context *ac, int order, int alloc_flags, > > */ > > if (order > PAGE_ALLOC_COSTLY_ORDER) > > max_retries /= 4; > > - if (compaction_retries <= max_retries) > > + if (*compaction_retries <= max_retries) > > return true; > > > > /* > > - * Make sure there is at least one attempt at the highest priority > > - * if we exhausted all retries at the lower priorities > > + * Make sure there are attempts at the highest priority if we exhausted > > + * all retries or failed at the lower priorities. > > */ > > check_priority: > > if (*compact_priority > MIN_COMPACT_PRIORITY) { > > (*compact_priority)--; > > + *compaction_retries = 0; > > return true; > > } > > return false; > > @@ -3224,7 +3225,7 @@ static inline bool > > should_compact_retry(struct alloc_context *ac, unsigned int order, int alloc_flags, > > enum compact_result compact_result, > > enum compact_priority *compact_priority, > > - int compaction_retries) > > + int *compaction_retries) > > { > > struct zone *zone; > > struct zoneref *z; > > @@ -3663,7 +3664,7 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order, > > if (did_some_progress > 0 && > > should_compact_retry(ac, order, alloc_flags, > > compact_result, &compact_priority, > > - compaction_retries)) > > + &compaction_retries)) > > goto retry; > > > > /* Reclaim has failed us, start killing things */ > > -- > > 2.10.0 > > > > -- > Michal Hocko > SUSE Labs -- Michal Hocko SUSE Labs
WARNING: multiple messages have this Message-ID
From: Michal Hocko <mhocko@kernel.org> To: Vlastimil Babka <vbabka@suse.cz> Cc: Andrew Morton <akpm@linux-foundation.org>, Arkadiusz Miskiewicz <a.miskiewicz@gmail.com>, Ralf-Peter Rohbeck <Ralf-Peter.Rohbeck@quantum.com>, Olaf Hering <olaf@aepfle.de>, linux-kernel@vger.kernel.org, Linus Torvalds <torvalds@linux-foundation.org>, linux-mm@kvack.org, Mel Gorman <mgorman@techsingularity.net>, Joonsoo Kim <iamjoonsoo.kim@lge.com>, David Rientjes <rientjes@google.com>, Rik van Riel <riel@redhat.com> Subject: Re: [PATCH 2/4] mm, compaction: more reliably increase direct compaction priority Date: Thu, 22 Sep 2016 16:52:37 +0200 [thread overview] Message-ID: <20160922145237.GH11875@dhcp22.suse.cz> (raw) In-Reply-To: <20160922140821.GG11875@dhcp22.suse.cz> On Thu 22-09-16 16:08:21, Michal Hocko wrote: > On Thu 22-09-16 14:51:48, Vlastimil Babka wrote: > > >From 465e1bd61b7a6d6901a44f09b1a76514dbc220fa Mon Sep 17 00:00:00 2001 > > From: Vlastimil Babka <vbabka@suse.cz> > > Date: Thu, 22 Sep 2016 13:54:32 +0200 > > Subject: [PATCH] mm, compaction: more reliably increase direct compaction > > priority-fix > > > > When increasing the compaction priority, also reset retries. Otherwise we can > > consume all retries on the lower priorities. > > OK, this is an improvement. I am just thinking that we might want to > pull > if (order && compaction_made_progress(compact_result)) > compaction_retries++; > > into should_compact_retry as well. I've had it there originally because > it was in line with no_progress_loops but now that we have compaction > priorities it would fit into retry logic better. As a plus it would > count only those compaction rounds where we we didn't have to rely on did that should be > the compaction retry logic. What do you think? > > > Suggested-by: Michal Hocko <mhocko@suse.com> > > Signed-off-by: Vlastimil Babka <vbabka@suse.cz> > > Anyway > Acked-by: Michal Hocko <mhocko@suse.com> > > > --- > > mm/page_alloc.c | 13 +++++++------ > > 1 file changed, 7 insertions(+), 6 deletions(-) > > > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > > index f8bed910e3cf..82fdb690ac62 100644 > > --- a/mm/page_alloc.c > > +++ b/mm/page_alloc.c > > @@ -3162,7 +3162,7 @@ static inline bool > > should_compact_retry(struct alloc_context *ac, int order, int alloc_flags, > > enum compact_result compact_result, > > enum compact_priority *compact_priority, > > - int compaction_retries) > > + int *compaction_retries) > > { > > int max_retries = MAX_COMPACT_RETRIES; > > > > @@ -3196,16 +3196,17 @@ should_compact_retry(struct alloc_context *ac, int order, int alloc_flags, > > */ > > if (order > PAGE_ALLOC_COSTLY_ORDER) > > max_retries /= 4; > > - if (compaction_retries <= max_retries) > > + if (*compaction_retries <= max_retries) > > return true; > > > > /* > > - * Make sure there is at least one attempt at the highest priority > > - * if we exhausted all retries at the lower priorities > > + * Make sure there are attempts at the highest priority if we exhausted > > + * all retries or failed at the lower priorities. > > */ > > check_priority: > > if (*compact_priority > MIN_COMPACT_PRIORITY) { > > (*compact_priority)--; > > + *compaction_retries = 0; > > return true; > > } > > return false; > > @@ -3224,7 +3225,7 @@ static inline bool > > should_compact_retry(struct alloc_context *ac, unsigned int order, int alloc_flags, > > enum compact_result compact_result, > > enum compact_priority *compact_priority, > > - int compaction_retries) > > + int *compaction_retries) > > { > > struct zone *zone; > > struct zoneref *z; > > @@ -3663,7 +3664,7 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order, > > if (did_some_progress > 0 && > > should_compact_retry(ac, order, alloc_flags, > > compact_result, &compact_priority, > > - compaction_retries)) > > + &compaction_retries)) > > goto retry; > > > > /* Reclaim has failed us, start killing things */ > > -- > > 2.10.0 > > > > -- > Michal Hocko > SUSE Labs -- Michal Hocko SUSE Labs -- 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>
next prev parent reply other threads:[~2016-09-22 14:52 UTC|newest] Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-09-06 13:52 [PATCH 0/4] reintroduce compaction feedback for OOM decisions Vlastimil Babka 2016-09-06 13:52 ` Vlastimil Babka 2016-09-06 13:52 ` [PATCH 1/4] Revert "mm, oom: prevent premature OOM killer invocation for high order request" Vlastimil Babka 2016-09-06 13:52 ` Vlastimil Babka 2016-09-21 17:04 ` Michal Hocko 2016-09-21 17:04 ` Michal Hocko 2016-09-06 13:52 ` [PATCH 2/4] mm, compaction: more reliably increase direct compaction priority Vlastimil Babka 2016-09-06 13:52 ` Vlastimil Babka 2016-09-21 17:13 ` Michal Hocko 2016-09-21 17:13 ` Michal Hocko 2016-09-22 12:51 ` Vlastimil Babka 2016-09-22 12:51 ` Vlastimil Babka 2016-09-22 14:08 ` Michal Hocko 2016-09-22 14:08 ` Michal Hocko 2016-09-22 14:52 ` Michal Hocko [this message] 2016-09-22 14:52 ` Michal Hocko 2016-09-22 14:59 ` Vlastimil Babka 2016-09-22 14:59 ` Vlastimil Babka 2016-09-22 15:06 ` Vlastimil Babka 2016-09-22 15:06 ` Vlastimil Babka 2016-09-23 4:04 ` Hillf Danton 2016-09-23 4:04 ` Hillf Danton 2016-09-23 6:55 ` Vlastimil Babka 2016-09-23 6:55 ` Vlastimil Babka 2016-09-23 8:23 ` Michal Hocko 2016-09-23 8:23 ` Michal Hocko 2016-09-23 10:47 ` Vlastimil Babka 2016-09-23 10:47 ` Vlastimil Babka 2016-09-23 12:06 ` Michal Hocko 2016-09-23 12:06 ` Michal Hocko 2016-09-06 13:52 ` [PATCH 3/4] mm, compaction: restrict full priority to non-costly orders Vlastimil Babka 2016-09-06 13:52 ` Vlastimil Babka 2016-09-21 17:15 ` Michal Hocko 2016-09-21 17:15 ` Michal Hocko 2016-09-06 13:52 ` [PATCH 4/4] mm, compaction: make full priority ignore pageblock suitability Vlastimil Babka 2016-09-06 13:52 ` Vlastimil Babka 2016-09-15 18:51 ` [PATCH 0/4] reintroduce compaction feedback for OOM decisions Arkadiusz Miskiewicz 2016-09-15 18:51 ` Arkadiusz Miskiewicz 2016-09-21 17:18 ` Michal Hocko 2016-09-21 17:18 ` Michal Hocko 2016-09-22 15:18 ` Vlastimil Babka 2016-09-22 15:18 ` Vlastimil Babka 2016-09-23 8:26 ` Michal Hocko 2016-09-23 8:26 ` Michal Hocko 2016-09-23 10:55 ` Vlastimil Babka 2016-09-23 10:55 ` Vlastimil Babka 2016-09-23 12:09 ` Michal Hocko 2016-09-23 12:09 ` Michal Hocko
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20160922145237.GH11875@dhcp22.suse.cz \ --to=mhocko@kernel.org \ --cc=Ralf-Peter.Rohbeck@quantum.com \ --cc=a.miskiewicz@gmail.com \ --cc=akpm@linux-foundation.org \ --cc=iamjoonsoo.kim@lge.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mgorman@techsingularity.net \ --cc=olaf@aepfle.de \ --cc=riel@redhat.com \ --cc=rientjes@google.com \ --cc=torvalds@linux-foundation.org \ --cc=vbabka@suse.cz \ --subject='Re: [PATCH 2/4] mm, compaction: more reliably increase direct compaction priority' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.