> But yes, such a deadlock is possible. I would really like to see the comments
> from maintainers. In particular, I seem to recall that someone suggested to
> try to kill another !TIF_MEMDIE process after timeout, perhaps this is what
> we should actually do...
Well yes here is a patch that kills another memdie process but there is
some risk with such an approach of overusing the reserves.
Subject: Allow multiple kills from the OOM killer
The OOM killer currently aborts if it finds a process that already is having
access to the reserve memory pool for exit processing. This is done so that
the reserves are not overcommitted but on the other hand this also allows
only one process being oom killed at the time. That process may be stuck
in D state.
The patch simply removes the aborting of the scan so that other processes
may be killed if one is stuck in D state.
Signed-off-by: Christoph Lameter <cl@xxxxxxxxx>
Index: linux/mm/oom_kill.c
===================================================================
--- linux.orig/mm/oom_kill.c 2015-09-18 10:38:29.601963726 -0500
+++ linux/mm/oom_kill.c 2015-09-18 10:39:55.911699017 -0500
@@ -265,8 +265,8 @@ enum oom_scan_t oom_scan_process_thread(
* Don't allow any other task to have access to the reserves.
*/
if (test_tsk_thread_flag(task, TIF_MEMDIE)) {
- if (oc->order != -1)
- return OOM_SCAN_ABORT;
+ if (unlikely(frozen(task)))
+ __thaw_task(task);
}
if (!task->mm)
return OOM_SCAN_CONTINUE;
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>