Messages in this thread | | | Date | Thu, 17 Sep 2015 21:22:04 +0200 | From | Oleg Nesterov <> | Subject | Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks |
| |
Add cc's.
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. > > Within oom_unkillable_task(), check for processes in > TASK_UNINTERRUPTIBLE (TASK_KILLABLE omitted). The oom killer will > move on to another task. > > Signed-off-by: Kyle Walker <kwalker@redhat.com> > --- > mm/oom_kill.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/mm/oom_kill.c b/mm/oom_kill.c > index 1ecc0bc..66f03f8 100644 > --- a/mm/oom_kill.c > +++ b/mm/oom_kill.c > @@ -131,6 +131,10 @@ static bool oom_unkillable_task(struct task_struct *p, > if (memcg && !task_in_mem_cgroup(p, memcg)) > return true; > > + /* Uninterruptible tasks should not be killed unless in TASK_WAKEKILL */ > + if (p->state == TASK_UNINTERRUPTIBLE) > + return true; > +
So we can skip a memory hog which, say, does mutex_lock(). And this can't help if this task is multithreaded, unless all its sub-threads are in "D" state too oom killer will pick another thread with the same ->mm. Plus other problems.
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...
Oleg.
| |