Re: [PATCH] kernel/hung_task.c: use timeout diff when timeout is updated

[Tetsuo Handa]

Andrew Morton wrote:
> On Thu, 17 Dec 2015 21:23:03 +0900 Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> wrote:
> 
> > >From 529ff00b556e110c6e801c39e94b06f559307136 Mon Sep 17 00:00:00 2001
> > From: Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx>
> > Date: Thu, 17 Dec 2015 16:27:08 +0900
> > Subject: [PATCH] kernel/hung_task.c: use timeout diff when timeout is updated
> > 
> > When new timeout is written to /proc/sys/kernel/hung_task_timeout_secs,
> > khungtaskd is interrupted and again sleeps for full timeout duration.
> > 
> > This means that hang task will not be checked if new timeout is written
> > periodically within old timeout duration and/or checking of hang task
> > will be delayed for up to previous timeout duration.
> > Fix this by remembering last time khungtaskd checked hang task.
> > 
> > This change will allow other watchdog tasks (if any) to share khungtaskd
> > by sleeping for minimal timeout diff of all watchdog tasks. Doing more
> > watchdog tasks from khungtaskd will reduce the possibility of printk()
> > collisions by multiple watchdog threads.
> 
> This seems like reasonable behaviour, but it is a
> non-backward-compatible change.  I don't know how important that is -
> probably "not very".
> 
> Please let's fully describe this behaviour in the documentation. 
> Documentation/sysctl/kernel.txt.
> 
> It appears that if userspace writes a new timeout which has already
> expired, a check is triggered immediately, correct?  Let's ensure that
> this is documented as well.   And tested!

Yes.

> 
> 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@xxxxxxxxxxxxxxxxxxx

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@xxxxxxxxxxxxxxxxxxx .

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?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/