From: Andrew Morton <akpm@linux-foundation.org>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: oleg@redhat.com, atomlin@redhat.com,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Michal Hocko <mhocko@kernel.org>
Subject: Re: [PATCH] kernel/hung_task.c: use timeout diff when timeout is updated
Date: Mon, 21 Dec 2015 13:45:45 -0800 [thread overview]
Message-ID: <20151221134545.cb0558878932913e348656e9@linux-foundation.org> (raw)
In-Reply-To: <201512212045.HHC00516.SQOJVHLFFtMOOF@I-love.SAKURA.ne.jp>
On Mon, 21 Dec 2015 20:45:23 +0900 Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> wrote:
> >
> > And it would be helpful to add a comment to hung_timeout_jiffies()
> > which describes the behaviour and explains the reasons for it.
>
> But before doing it, I'd like to confirm hung task maintainer's will.
>
> The reason I proposed this patch is that I want to add a watchdog task
> which emits warning messages when memory allocations are stalling.
> http://lkml.kernel.org/r/201512130033.ABH90650.FtFOMOFLVOJHQS@I-love.SAKURA.ne.jp
>
> But concurrently emitting multiple backtraces is problematic. Concurrent
> emitting by hung task watchdog and memory allocation stall watchdog is very
> likely to occur, for it is likely that other task is also stuck in
> uninterruptible sleep when one task got stuck at memory allocation.
>
> Therefore, I started trying to use same thread for both watchdogs.
> A draft patch is at
> http://lkml.kernel.org/r/201512170011.IAC73451.FLtFMSJHOQFVOO@I-love.SAKURA.ne.jp .
>
> If you prefer current hang task behavior, I'll try to preseve current
> behavior. Instead, I might use two threads and try to mutex both watchdogs
> using console_lock() or something like that.
>
> So, may I ask what your preference is?
I've added linux-mm to Cc. Please never forget that.
The general topic here is "add more diagnostics around an out-of-memory
event". Clearly we need this, but Michal is working on the same thing
as part of his "OOM detection rework v4" work, so can we please do the
appropriate coordination and review there?
Preventing watchdog-triggered backtraces from messing each other up is
of course a good idea. Your malloc watchdog patch adds a surprising
amount of code and adding yet another kernel thread is painful but
perhaps it's all worth it. It's a matter of people reviewing, testing
and using the code in realistic situations and that process has hardly
begun, alas.
Sorry, that was waffly but I don't feel able to be more definite at
this time.
--
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 parent reply other threads:[~2015-12-21 21:45 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <201512172123.DFJ69220.SFFOLOJtVHOQMF@I-love.SAKURA.ne.jp>
[not found] ` <20151217141805.f418cf9b137da08656504001@linux-foundation.org>
[not found] ` <201512212045.HHC00516.SQOJVHLFFtMOOF@I-love.SAKURA.ne.jp>
2015-12-21 21:45 ` Andrew Morton [this message]
2016-01-20 21:05 ` Andrew Morton
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=20151221134545.cb0558878932913e348656e9@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=atomlin@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=oleg@redhat.com \
--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