From: Roman Gushchin <guro@fb.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH v2] mm,oom: add tracepoints for oom reaper-related events
Date: Tue, 20 Jun 2017 14:43:35 +0100 [thread overview]
Message-ID: <20170620134335.GA17724@castle> (raw)
In-Reply-To: <20170602081338.GD29840@dhcp22.suse.cz>
Hi Andrew!
Can you, please, pull this patch?
Thank you!
Roman
On Fri, Jun 02, 2017 at 10:13:38AM +0200, Michal Hocko wrote:
> On Thu 01-06-17 19:41:13, Roman Gushchin wrote:
> > On Wed, May 31, 2017 at 06:39:29PM +0200, Michal Hocko wrote:
> > > On Tue 30-05-17 19:52:31, Roman Gushchin wrote:
> > > > >From c57e3674efc609f8364f5e228a2c1309cfe99901 Mon Sep 17 00:00:00 2001
> > > > From: Roman Gushchin <guro@fb.com>
> > > > Date: Tue, 23 May 2017 17:37:55 +0100
> > > > Subject: [PATCH v2] mm,oom: add tracepoints for oom reaper-related events
> > > >
> > > > During the debugging of the problem described in
> > > > https://lkml.org/lkml/2017/5/17/542 and fixed by Tetsuo Handa
> > > > in https://lkml.org/lkml/2017/5/19/383 , I've found that
> > > > the existing debug output is not really useful to understand
> > > > issues related to the oom reaper.
> > > >
> > > > So, I assume, that adding some tracepoints might help with
> > > > debugging of similar issues.
> > > >
> > > > Trace the following events:
> > > > 1) a process is marked as an oom victim,
> > > > 2) a process is added to the oom reaper list,
> > > > 3) the oom reaper starts reaping process's mm,
> > > > 4) the oom reaper finished reaping,
> > > > 5) the oom reaper skips reaping.
> > > >
> > > > How it works in practice? Below is an example which show
> > > > how the problem mentioned above can be found: one process is added
> > > > twice to the oom_reaper list:
> > > >
> > > > $ cd /sys/kernel/debug/tracing
> > > > $ echo "oom:mark_victim" > set_event
> > > > $ echo "oom:wake_reaper" >> set_event
> > > > $ echo "oom:skip_task_reaping" >> set_event
> > > > $ echo "oom:start_task_reaping" >> set_event
> > > > $ echo "oom:finish_task_reaping" >> set_event
> > > > $ cat trace_pipe
> > > > allocate-502 [001] .... 91.836405: mark_victim: pid=502
> > > > allocate-502 [001] .N.. 91.837356: wake_reaper: pid=502
> > > > allocate-502 [000] .N.. 91.871149: wake_reaper: pid=502
> > > > oom_reaper-23 [000] .... 91.871177: start_task_reaping: pid=502
> > > > oom_reaper-23 [000] .N.. 91.879511: finish_task_reaping: pid=502
> > > > oom_reaper-23 [000] .... 91.879580: skip_task_reaping: pid=502
> > >
> > > OK, this is much better! The clue here would be that we got 2
> > > wakeups for the same task, right?
> > > Do you think it would make sense to put more context to those
> > > tracepoints? E.g. skip_task_reaping can be due to lock contention or the
> > > mm gone. wake_reaper is similar.
> >
> > I agree, that some context might be useful under some circumstances,
> > but I don't think we should add any additional fields until we will have some examples
> > of where this data is actually useful. If we will need it, we can easily add it later.
>
> OK, fair enough.
>
> Acked-by: Michal Hocko <mhocko@suse.com>
> --
> 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>
prev parent reply other threads:[~2017-06-20 13:44 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-30 12:05 [PATCH] mm,oom: add tracepoints for oom reaper-related events Roman Gushchin
2017-05-30 12:34 ` Michal Hocko
2017-05-30 13:17 ` Tetsuo Handa
2017-05-30 13:33 ` Roman Gushchin
2017-05-30 13:45 ` Michal Hocko
2017-05-30 18:52 ` [PATCH v2] " Roman Gushchin
2017-05-31 16:39 ` Michal Hocko
2017-06-01 18:41 ` Roman Gushchin
2017-06-02 8:13 ` Michal Hocko
2017-06-20 13:43 ` Roman Gushchin [this message]
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=20170620134335.GA17724@castle \
--to=guro@fb.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).