Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks

Kyle Walker wrote: > I agree, in lieu of treating TASK_UNINTERRUPTIBLE tasks as unkillable, > and omitting them from the oom selection process, continuing the > carnage is likely to result in more unpredictable results. At this > time, I believe Oleg's solution of zapping the process memory use >

Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks

Kyle Walker wrote: > I agree, in lieu of treating TASK_UNINTERRUPTIBLE tasks as unkillable, > and omitting them from the oom selection process, continuing the > carnage is likely to result in more unpredictable results. At this > time, I believe Oleg's solution of zapping the process memory use >

Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks

On Tue, Sep 22, 2015 at 7:32 PM, David Rientjes wrote: > > I struggle to understand how the approach of randomly continuing to kill > more and more processes in the hope that it slows down usage of memory > reserves or that we get lucky is better. Thank you to one and all for the feedback. I

Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks

On Tue, Sep 22, 2015 at 7:32 PM, David Rientjes wrote: > > I struggle to understand how the approach of randomly continuing to kill > more and more processes in the hope that it slows down usage of memory > reserves or that we get lucky is better. Thank you to one and all

Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks

On Tue, 22 Sep 2015, Tetsuo Handa wrote: > David Rientjes wrote: > > Your proposal, which I mostly agree with, tries to kill additional > > processes so that they allocate and drop the lock that the original victim > > depends on. My approach, from > >

Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks

On Tue, 22 Sep 2015, Tetsuo Handa wrote: > David Rientjes wrote: > > Your proposal, which I mostly agree with, tries to kill additional > > processes so that they allocate and drop the lock that the original victim > > depends on. My approach, from > >

Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks

David Rientjes wrote: > Your proposal, which I mostly agree with, tries to kill additional > processes so that they allocate and drop the lock that the original victim > depends on. My approach, from > http://marc.info/?l=linux-kernel=144010444913702, is the same, but > without the killing.

Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks

On Sat, 19 Sep 2015, Tetsuo Handa wrote: > I think that use of ALLOC_NO_WATERMARKS via TIF_MEMDIE is the underlying > cause. ALLOC_NO_WATERMARKS via TIF_MEMDIE is intended for terminating the > OOM victim task as soon as possible, but it turned out that it will not > work if there is invisible

Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks

On Fri, 18 Sep 2015, Christoph Lameter wrote: > 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

Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks

On Sat, 19 Sep 2015, Michal Hocko wrote: > Nack to this. TASK_UNINTERRUPTIBLE should be time constrained/bounded > state. Using it as an oom victim criteria makes the victim selection > less deterministic which is undesirable. As much as I am aware of > potential issues with the current

Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks

David Rientjes wrote: > Your proposal, which I mostly agree with, tries to kill additional > processes so that they allocate and drop the lock that the original victim > depends on. My approach, from > http://marc.info/?l=linux-kernel=144010444913702, is the same, but > without the killing.

Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks

On Sat, 19 Sep 2015, Tetsuo Handa wrote: > I think that use of ALLOC_NO_WATERMARKS via TIF_MEMDIE is the underlying > cause. ALLOC_NO_WATERMARKS via TIF_MEMDIE is intended for terminating the > OOM victim task as soon as possible, but it turned out that it will not > work if there is invisible

Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks

On Sat, 19 Sep 2015, Michal Hocko wrote: > Nack to this. TASK_UNINTERRUPTIBLE should be time constrained/bounded > state. Using it as an oom victim criteria makes the victim selection > less deterministic which is undesirable. As much as I am aware of > potential issues with the current

Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks

On Fri, 18 Sep 2015, Christoph Lameter wrote: > 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

Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks

On Sat 19-09-15 23:33:07, Tetsuo Handa wrote: > Michal Hocko wrote: > > This has been posted in various forms many times over past years. I > > still do not think this is a right approach of dealing with the problem. > > I do not think "GFP_NOFS can fail" patch is a right approach because > that

Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks

On 09/19, Michal Hocko wrote: > > This has been posted in various forms many times over past years. I > still do not think this is a right approach of dealing with the problem. Agreed. But still I think it makes sense to try to kill another task if the victim refuse to die. Yes, the details are

Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks

Michal Hocko wrote: > This has been posted in various forms many times over past years. I > still do not think this is a right approach of dealing with the problem. I do not think "GFP_NOFS can fail" patch is a right approach because that patch easily causes messages like below. Buffer I/O

Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks

On Fri 18-09-15 12:00:59, Christoph Lameter wrote: [...] > 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

Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks

On Fri 18-09-15 10:41:09, Christoph Lameter wrote: [...] > if (test_tsk_thread_flag(task, TIF_MEMDIE)) { > - if (oc->order != -1) > - return OOM_SCAN_ABORT; > + if (unlikely(frozen(task))) > + __thaw_task(task); TIF_MEMDIE

Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks

On Thu 17-09-15 13:59:43, 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

Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks

On Fri 18-09-15 12:00:59, Christoph Lameter wrote: [...] > 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

Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks

On Fri 18-09-15 10:41:09, Christoph Lameter wrote: [...] > if (test_tsk_thread_flag(task, TIF_MEMDIE)) { > - if (oc->order != -1) > - return OOM_SCAN_ABORT; > + if (unlikely(frozen(task))) > + __thaw_task(task); TIF_MEMDIE

Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks

On Thu 17-09-15 13:59:43, 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

Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks

On 09/19, Michal Hocko wrote: > > This has been posted in various forms many times over past years. I > still do not think this is a right approach of dealing with the problem. Agreed. But still I think it makes sense to try to kill another task if the victim refuse to die. Yes, the details are

Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks

Michal Hocko wrote: > This has been posted in various forms many times over past years. I > still do not think this is a right approach of dealing with the problem. I do not think "GFP_NOFS can fail" patch is a right approach because that patch easily causes messages like below. Buffer I/O

Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks

On Sat 19-09-15 23:33:07, Tetsuo Handa wrote: > Michal Hocko wrote: > > This has been posted in various forms many times over past years. I > > still do not think this is a right approach of dealing with the problem. > > I do not think "GFP_NOFS can fail" patch is a right approach because > that

Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks

On Fri, 18 Sep 2015, Kyle Walker wrote: > I do like the idea of not stalling completely in an oom just because the > first attempt didn't go so well. Is there any possibility of simply having > our cake and eating it too? Specifically, omitting TASK_UNINTERRUPTIBLE > tasks > as low-hanging fruit

Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks

On Fri, 18 Sep 2015, Oleg Nesterov wrote: > And btw. Yes, this is a bit off-topic, but I think another change make > sense too. We should report the fact we are going to kill another task > because the previous victim refuse to die, and print its stack trace. What happens is that the previous

Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks

On 09/18, Christoph Lameter wrote: > > --- linux.orig/mm/oom_kill.c 2015-09-18 11:58:52.963946782 -0500 > +++ linux/mm/oom_kill.c 2015-09-18 11:59:42.010684778 -0500 > @@ -264,10 +264,9 @@ enum oom_scan_t oom_scan_process_thread( >* This task already has access to memory reserves

Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks

On Fri, 18 Sep 2015, Oleg Nesterov wrote: > To simplify the discussion lets ignore PF_FROZEN, this is another issue. Ok. 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

Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks

On 09/19, Tetsuo Handa wrote: > > Oleg Nesterov wrote: > > To simplify the discussion lets ignore PF_FROZEN, this is another issue. > > > > I am not sure this change is enough, we need to ensure that > > select_bad_process() won't pick the same task (or its sub-thread) again. > > SysRq-f is

Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks

Oleg Nesterov wrote: > To simplify the discussion lets ignore PF_FROZEN, this is another issue. > > I am not sure this change is enough, we need to ensure that > select_bad_process() won't pick the same task (or its sub-thread) again. SysRq-f is sometimes unusable because it continues choosing

Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks

On 09/18, Christoph Lameter wrote: > > > 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

Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks

> 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

Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks

On 09/18, Christoph Lameter wrote: > > --- linux.orig/mm/oom_kill.c 2015-09-18 11:58:52.963946782 -0500 > +++ linux/mm/oom_kill.c 2015-09-18 11:59:42.010684778 -0500 > @@ -264,10 +264,9 @@ enum oom_scan_t oom_scan_process_thread( >* This task already has access to memory reserves

Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks

On Fri, 18 Sep 2015, Oleg Nesterov wrote: > And btw. Yes, this is a bit off-topic, but I think another change make > sense too. We should report the fact we are going to kill another task > because the previous victim refuse to die, and print its stack trace. What happens is that the previous

Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks

On Fri, 18 Sep 2015, Kyle Walker wrote: > I do like the idea of not stalling completely in an oom just because the > first attempt didn't go so well. Is there any possibility of simply having > our cake and eating it too? Specifically, omitting TASK_UNINTERRUPTIBLE > tasks > as low-hanging fruit

Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks

Oleg Nesterov wrote: > To simplify the discussion lets ignore PF_FROZEN, this is another issue. > > I am not sure this change is enough, we need to ensure that > select_bad_process() won't pick the same task (or its sub-thread) again. SysRq-f is sometimes unusable because it continues choosing

Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks

On 09/19, Tetsuo Handa wrote: > > Oleg Nesterov wrote: > > To simplify the discussion lets ignore PF_FROZEN, this is another issue. > > > > I am not sure this change is enough, we need to ensure that > > select_bad_process() won't pick the same task (or its sub-thread) again. > > SysRq-f is

Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks

On Fri, 18 Sep 2015, Oleg Nesterov wrote: > To simplify the discussion lets ignore PF_FROZEN, this is another issue. Ok. 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

Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks

On 09/18, Christoph Lameter wrote: > > > 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

Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks

> 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

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

[PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks

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

[PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks

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

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