[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170530133335.GB28148@castle>
Date: Tue, 30 May 2017 14:33:35 +0100
From: Roman Gushchin <guro@...com>
To: Michal Hocko <mhocko@...nel.org>
CC: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
Johannes Weiner <hannes@...xchg.org>,
Vladimir Davydov <vdavydov.dev@...il.com>,
<kernel-team@...com>, <linux-kernel@...r.kernel.org>,
<linux-mm@...ck.org>
Subject: Re: [PATCH] mm,oom: add tracepoints for oom reaper-related events
On Tue, May 30, 2017 at 02:34:16PM +0200, Michal Hocko wrote:
> On Tue 30-05-17 13:05:32, Roman Gushchin wrote:
> > Add tracepoints to simplify the debugging of the oom reaper code.
> >
> > 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.
>
> I am not against but could you explain why the current printks are not
> sufficient? We do not have any explicit printk for the 2) and 3) but
> are those really necessary?
We also don't have any printks for 1) and 2) if, for, instance, we call
out_of_memory() and task_will_free_mem(current) returns true.
>
> In other words could you describe the situation when you found these
> tracepoints more useful than what the kernel log offers already?
During my work on cgroup-aware OOM killer and some issues discovered
in process (which are described in https://lkml.org/lkml/2017/5/17/542;
most important problem fixed by Tetsuo), I've found an existing debug output
insufficient and sometimes too bulky.
Suggested traces allowed me to debug issues like I've met (double invocation
of oom_reaper, etc) much easier.
Thanks!
Roman
Powered by blists - more mailing lists