From: David Rientjes <rientjes@google.com>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: Michal Hocko <mhocko@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [patch] mm, oom: dump stack of victim when reaping failed
Date: Wed, 15 Jan 2020 12:27:09 -0800 (PST) [thread overview]
Message-ID: <alpine.DEB.2.21.2001151223040.13588@chino.kir.corp.google.com> (raw)
In-Reply-To: <9a7cbbf0-4283-f932-e422-84b4fb42a055@I-love.SAKURA.ne.jp>
On Wed, 15 Jan 2020, Tetsuo Handa wrote:
> >> When a process cannot be oom reaped, for whatever reason, currently the
> >> list of locks that are held is currently dumped to the kernel log.
> >>
> >> Much more interesting is the stack trace of the victim that cannot be
> >> reaped. If the stack trace is dumped, we have the ability to find
> >> related occurrences in the same kernel code and hopefully solve the
> >> issue that is making it wedged.
> >>
> >> Dump the stack trace when a process fails to be oom reaped.
> >
> > Yes, this is really helpful.
>
> tsk would be a thread group leader, but the thread which got stuck is not
> always a thread group leader. Maybe dump all threads in that thread group
> without PF_EXITING (or something) ?
>
That's possible, yes. I think it comes down to the classic problem of how
much info in the kernel log on oom kill is too much. Stacks for all
threads that match the mm being reaped may be *very* verbose. I'm
currently tracking a stall in oom reaping where the victim doesn't always
have a lock held so we don't know where it's at in the kernel; I'm hoping
that a stack for the thread group leader will at least shed some light on
it.
next prev parent reply other threads:[~2020-01-15 20:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-14 23:20 [patch] mm, oom: dump stack of victim when reaping failed David Rientjes
2020-01-15 8:43 ` Michal Hocko
2020-01-15 9:18 ` Tetsuo Handa
2020-01-15 20:27 ` David Rientjes [this message]
2020-01-15 21:09 ` Tetsuo Handa
2020-01-16 21:05 ` David Rientjes
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=alpine.DEB.2.21.2001151223040.13588@chino.kir.corp.google.com \
--to=rientjes@google.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=penguin-kernel@i-love.sakura.ne.jp \
/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).