Re: [RFC][PATCH] sysrq: ensure manual invocation of the OOM killer under OOM livelock

[Michal Hocko]

On Wed 30-12-15 15:33:47, Tetsuo Handa wrote:
> >From 7fcac2054b33dc3df6c5915a58f232b9b80bb1e6 Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx>
> Date: Wed, 30 Dec 2015 15:24:40 +0900
> Subject: [RFC][PATCH] sysrq: ensure manual invocation of the OOM killer under OOM livelock
> 
> This patch is similar to what commit 373ccbe5927034b5 ("mm, vmstat:
> allow WQ concurrency to discover memory reclaim doesn't make any
> progress") does, but this patch is for SysRq-f.
>
> SysRq-f is a method for reclaiming memory by manually invoking the OOM
> killer. Therefore, it needs to be invokable even when the system is
> looping under OOM livelock condition.

Yes this makes a lot of sense and thanks for doing it. I have it on my
todo list but didn't get to it yet. I guess this is not only sysrq+f
specific though. What about emergency reboot or manual crash invocation?

I think all of them deserve an immediate action and so they should share
the same wq.
 
> While making sure that we give workqueue items a chance to run is
> done by "mm,oom: Always sleep before retrying." patch, allocating
> a dedicated workqueue only for SysRq-f might be too wasteful when
> there is the OOM reaper kernel thread which will be idle when
> we need to use SysRq-f due to OOM livelock condition.
> 
> I wish for a kernel thread that does OOM-kill operation.
> Maybe we can change the OOM reaper kernel thread to do it.
> What do you think?

I do no think a separate kernel thread would help much if the
allocations have to keep looping in the allocator. oom_reaper is a
separate kernel thread only due to locking required for the exit_mmap
path.

-- 
Michal Hocko
SUSE Labs
--
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/