From: Michal Hocko <mhocko@kernel.org> To: Vlastimil Babka <vbabka@suse.cz> Cc: Andrew Morton <akpm@linux-foundation.org>, David Rientjes <rientjes@google.com>, Johannes Weiner <hannes@cmpxchg.org>, linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org> Subject: Re: [PATCH 3/3] oom, trace: add compaction retry tracepoint Date: Wed, 4 Jan 2017 11:56:29 +0100 [thread overview] Message-ID: <20170104105629.GF25453@dhcp22.suse.cz> (raw) In-Reply-To: <6f3a808d-7799-80f5-9c00-4fb996dc31fa@suse.cz> On Wed 04-01-17 11:47:56, Vlastimil Babka wrote: > On 12/20/2016 02:01 PM, Michal Hocko wrote: > > From: Michal Hocko <mhocko@suse.com> > > > > Higher order requests oom debugging is currently quite hard. We do have > > some compaction points which can tell us how the compaction is operating > > but there is no trace point to tell us about compaction retry logic. > > This patch adds a one which will have the following format > > > > bash-3126 [001] .... 1498.220001: compact_retry: order=9 priority=COMPACT_PRIO_SYNC_LIGHT compaction_result=withdrawn retries=0 max_retries=16 should_retry=0 > > > > we can see that the order 9 request is not retried even though we are in > > the highest compaction priority mode becase the last compaction attempt > > was withdrawn. This means that compaction_zonelist_suitable must have > > returned false and there is no suitable zone to compact for this request > > and so no need to retry further. > > > > another example would be > > <...>-3137 [001] .... 81.501689: compact_retry: order=9 priority=COMPACT_PRIO_SYNC_LIGHT compaction_result=failed retries=0 max_retries=16 should_retry=0 > > > > in this case the order-9 compaction failed to find any suitable > > block. We do not retry anymore because this is a costly request > > and those do not go below COMPACT_PRIO_SYNC_LIGHT priority. > > > > Changes since v1 > > - fix compaction_result into highlevel constants translation as per > > Vlastimil > > > > Signed-off-by: Michal Hocko <mhocko@suse.com> > > Acked-by: Vlastimil Babka <vbabka@suse.cz> > > Hmm I've noticed that I didn't suggest the following below here, > although I did for the vmscan tracepoints now. How about adding this > -fix for consistency? > > --------8<-------- > From: Vlastimil Babka <vbabka@suse.cz> > Date: Wed, 4 Jan 2017 11:44:09 +0100 > Subject: [PATCH] oom, trace: add compaction retry tracepoint-fix > > Let's print the compaction priorities lower-case and without > prefix for consistency. > > Also indent fix in compact_result_to_feedback(). > > Signed-off-by: Vlastimil Babka <vbabka@suse.cz> I would just worry that c&p constant name is easier to work with when vim -t $PRIO or git grep $PRIO. But if the lowercase and shorter sounds better to you then no objections from me. > --- > include/trace/events/mmflags.h | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/include/trace/events/mmflags.h b/include/trace/events/mmflags.h > index aa4caa6914a9..e4c3a0febcce 100644 > --- a/include/trace/events/mmflags.h > +++ b/include/trace/events/mmflags.h > @@ -195,7 +195,7 @@ IF_HAVE_VM_SOFTDIRTY(VM_SOFTDIRTY, "softdirty" ) \ > > #define compact_result_to_feedback(result) \ > ({ \ > - enum compact_result __result = result; \ > + enum compact_result __result = result; \ > (compaction_failed(__result)) ? COMPACTION_FAILED : \ > (compaction_withdrawn(__result)) ? COMPACTION_WITHDRAWN : COMPACTION_PROGRESS; \ > }) > @@ -206,9 +206,9 @@ IF_HAVE_VM_SOFTDIRTY(VM_SOFTDIRTY, "softdirty" ) \ > EMe(COMPACTION_PROGRESS, "progress") > > #define COMPACTION_PRIORITY \ > - EM(COMPACT_PRIO_SYNC_FULL, "COMPACT_PRIO_SYNC_FULL") \ > - EM(COMPACT_PRIO_SYNC_LIGHT, "COMPACT_PRIO_SYNC_LIGHT") \ > - EMe(COMPACT_PRIO_ASYNC, "COMPACT_PRIO_ASYNC") > + EM(COMPACT_PRIO_SYNC_FULL, "sync_full") \ > + EM(COMPACT_PRIO_SYNC_LIGHT, "sync_light") \ > + EMe(COMPACT_PRIO_ASYNC, "async") > #else > #define COMPACTION_STATUS > #define COMPACTION_PRIORITY > -- > 2.11.0 > -- Michal Hocko SUSE Labs
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org> To: Vlastimil Babka <vbabka@suse.cz> Cc: Andrew Morton <akpm@linux-foundation.org>, David Rientjes <rientjes@google.com>, Johannes Weiner <hannes@cmpxchg.org>, linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org> Subject: Re: [PATCH 3/3] oom, trace: add compaction retry tracepoint Date: Wed, 4 Jan 2017 11:56:29 +0100 [thread overview] Message-ID: <20170104105629.GF25453@dhcp22.suse.cz> (raw) In-Reply-To: <6f3a808d-7799-80f5-9c00-4fb996dc31fa@suse.cz> On Wed 04-01-17 11:47:56, Vlastimil Babka wrote: > On 12/20/2016 02:01 PM, Michal Hocko wrote: > > From: Michal Hocko <mhocko@suse.com> > > > > Higher order requests oom debugging is currently quite hard. We do have > > some compaction points which can tell us how the compaction is operating > > but there is no trace point to tell us about compaction retry logic. > > This patch adds a one which will have the following format > > > > bash-3126 [001] .... 1498.220001: compact_retry: order=9 priority=COMPACT_PRIO_SYNC_LIGHT compaction_result=withdrawn retries=0 max_retries=16 should_retry=0 > > > > we can see that the order 9 request is not retried even though we are in > > the highest compaction priority mode becase the last compaction attempt > > was withdrawn. This means that compaction_zonelist_suitable must have > > returned false and there is no suitable zone to compact for this request > > and so no need to retry further. > > > > another example would be > > <...>-3137 [001] .... 81.501689: compact_retry: order=9 priority=COMPACT_PRIO_SYNC_LIGHT compaction_result=failed retries=0 max_retries=16 should_retry=0 > > > > in this case the order-9 compaction failed to find any suitable > > block. We do not retry anymore because this is a costly request > > and those do not go below COMPACT_PRIO_SYNC_LIGHT priority. > > > > Changes since v1 > > - fix compaction_result into highlevel constants translation as per > > Vlastimil > > > > Signed-off-by: Michal Hocko <mhocko@suse.com> > > Acked-by: Vlastimil Babka <vbabka@suse.cz> > > Hmm I've noticed that I didn't suggest the following below here, > although I did for the vmscan tracepoints now. How about adding this > -fix for consistency? > > --------8<-------- > From: Vlastimil Babka <vbabka@suse.cz> > Date: Wed, 4 Jan 2017 11:44:09 +0100 > Subject: [PATCH] oom, trace: add compaction retry tracepoint-fix > > Let's print the compaction priorities lower-case and without > prefix for consistency. > > Also indent fix in compact_result_to_feedback(). > > Signed-off-by: Vlastimil Babka <vbabka@suse.cz> I would just worry that c&p constant name is easier to work with when vim -t $PRIO or git grep $PRIO. But if the lowercase and shorter sounds better to you then no objections from me. > --- > include/trace/events/mmflags.h | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/include/trace/events/mmflags.h b/include/trace/events/mmflags.h > index aa4caa6914a9..e4c3a0febcce 100644 > --- a/include/trace/events/mmflags.h > +++ b/include/trace/events/mmflags.h > @@ -195,7 +195,7 @@ IF_HAVE_VM_SOFTDIRTY(VM_SOFTDIRTY, "softdirty" ) \ > > #define compact_result_to_feedback(result) \ > ({ \ > - enum compact_result __result = result; \ > + enum compact_result __result = result; \ > (compaction_failed(__result)) ? COMPACTION_FAILED : \ > (compaction_withdrawn(__result)) ? COMPACTION_WITHDRAWN : COMPACTION_PROGRESS; \ > }) > @@ -206,9 +206,9 @@ IF_HAVE_VM_SOFTDIRTY(VM_SOFTDIRTY, "softdirty" ) \ > EMe(COMPACTION_PROGRESS, "progress") > > #define COMPACTION_PRIORITY \ > - EM(COMPACT_PRIO_SYNC_FULL, "COMPACT_PRIO_SYNC_FULL") \ > - EM(COMPACT_PRIO_SYNC_LIGHT, "COMPACT_PRIO_SYNC_LIGHT") \ > - EMe(COMPACT_PRIO_ASYNC, "COMPACT_PRIO_ASYNC") > + EM(COMPACT_PRIO_SYNC_FULL, "sync_full") \ > + EM(COMPACT_PRIO_SYNC_LIGHT, "sync_light") \ > + EMe(COMPACT_PRIO_ASYNC, "async") > #else > #define COMPACTION_STATUS > #define COMPACTION_PRIORITY > -- > 2.11.0 > -- 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:[~2017-01-04 10:57 UTC|newest] Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-12-20 13:01 [PATCH 0/3 v2] mm, oom: add oom detection tracepoints Michal Hocko 2016-12-20 13:01 ` Michal Hocko 2016-12-20 13:01 ` [PATCH 1/3] mm, trace: extract COMPACTION_STATUS and ZONE_TYPE to a common header Michal Hocko 2016-12-20 13:01 ` Michal Hocko 2016-12-20 13:01 ` [PATCH 2/3] oom, trace: Add oom detection tracepoints Michal Hocko 2016-12-20 13:01 ` Michal Hocko 2016-12-20 13:01 ` [PATCH 3/3] oom, trace: add compaction retry tracepoint Michal Hocko 2016-12-20 13:01 ` Michal Hocko 2017-01-04 10:47 ` Vlastimil Babka 2017-01-04 10:47 ` Vlastimil Babka 2017-01-04 10:56 ` Michal Hocko [this message] 2017-01-04 10:56 ` Michal Hocko 2017-01-04 14:49 ` Vlastimil Babka 2017-01-04 14:49 ` Vlastimil Babka -- strict thread matches above, loose matches on Subject: below -- 2016-12-14 14:53 [PATCH 0/3] mm, oom: add oom detection tracepoints Michal Hocko 2016-12-14 14:53 ` [PATCH 3/3] oom, trace: add compaction retry tracepoint Michal Hocko 2016-12-14 14:53 ` Michal Hocko 2016-12-14 17:28 ` Vlastimil Babka 2016-12-14 17:28 ` Vlastimil Babka 2016-12-14 18:11 ` Michal Hocko 2016-12-14 18:11 ` Michal Hocko 2016-12-15 8:18 ` Vlastimil Babka 2016-12-15 8:18 ` Vlastimil Babka
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=20170104105629.GF25453@dhcp22.suse.cz \ --to=mhocko@kernel.org \ --cc=akpm@linux-foundation.org \ --cc=hannes@cmpxchg.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=rientjes@google.com \ --cc=vbabka@suse.cz \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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.