Oleg Nesterov wrote: > On 09/17, Kyle Walker wrote: > > > > Currently, the oom killer will attempt to kill a process that is in > > TASK_UNINTERRUPTIBLE state. For tasks in this state for an exceptional > > period of time, such as processes writing to a frozen filesystem during > > a lengthy backup operation, this can result in a deadlock condition as > > related processes memory access will stall within the page fault > > handler. > > And there are other potential reasons for deadlock. > > Stupid idea. Can't we help the memory hog to free its memory? This is > orthogonal to other improvements we can do. So, we are trying to release memory without waiting for arriving at exit_mm() from do_exit(), right? If it works, it will be a simple and small change that will be easy to backport. The idea is that since fatal_signal_pending() tasks no longer return to user space, we can release memory allocated for use by user space, right? Then, I think that this approach can be applied to not only OOM-kill case but also regular kill(pid, SIGKILL) case (i.e. kick from signal_wake_up(1) or somewhere?). A dedicated kernel thread (not limited to OOM-kill purpose) scans for fatal_signal_pending() tasks and release that task's memory. -- 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>