On Wed 30-12-15 15:33:47, Tetsuo Handa wrote: > >From 7fcac2054b33dc3df6c5915a58f232b9b80bb1e6 Mon Sep 17 00:00:00 2001 > From: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/