From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-f174.google.com (mail-qk0-f174.google.com [209.85.220.174]) by kanga.kvack.org (Postfix) with ESMTP id 2C2456B0038 for ; Fri, 18 Sep 2015 17:28:38 -0400 (EDT) Received: by qkcf65 with SMTP id f65so24883729qkc.3 for ; Fri, 18 Sep 2015 14:28:38 -0700 (PDT) Received: from mail-qg0-f51.google.com (mail-qg0-f51.google.com. [209.85.192.51]) by mx.google.com with ESMTPS id 79si9950916qgc.83.2015.09.18.14.28.37 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Sep 2015 14:28:37 -0700 (PDT) Received: by qgev79 with SMTP id v79so49426186qge.0 for ; Fri, 18 Sep 2015 14:28:37 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <1442512783-14719-1-git-send-email-kwalker@redhat.com> <20150917192204.GA2728@redhat.com> <20150918162423.GA18136@redhat.com> <20150918190725.GA24989@redhat.com> Date: Fri, 18 Sep 2015 17:28:36 -0400 Message-ID: Subject: Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks From: Kyle Walker Content-Type: multipart/alternative; boundary=001a113a8a1af1989c05200c3603 Sender: owner-linux-mm@kvack.org List-ID: To: Christoph Lameter Cc: Oleg Nesterov , akpm@linux-foundation.org, mhocko@suse.cz, rientjes@google.com, hannes@cmpxchg.org, vdavydov@parallels.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Tetsuo Handa , Stanislav Kozina --001a113a8a1af1989c05200c3603 Content-Type: text/plain; charset=UTF-8 > 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. Thank you for the review and feedback! I think that would definitely be a nice touch. I would definitely throw my hat in as wanting the above, but in the interests of keeping things as simple as possible, I kept myself out of that level of change. > What happens is that the previous victim did not enter exit processing. If > it would then it would be excluded by other checks. The first victim never > reacted and never started using the memory resources available for > exiting. Thats why I thought it maybe safe to go this way. > > An issue could result from another process being terminated and the first > victim finally reacting to the signal and also beginning termination. Then > we have contention on the reserves. > 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 and allowing the oom to continue in the event that the first attempt stalls? Just a thought. --001a113a8a1af1989c05200c3603 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> On Fri, 18 Sep 2015, Oleg Nesterov wrote:
> > And btw. Yes, this is a bit off-topic, but I think another cha= nge make
> > sense too. We should report the fact we are= going to kill another task
> > because the previous vi= ctim refuse to die, and print its stack trace.

Thank you for the review and feedback! I think that would definitely be = a
nice touch. I would definitely throw my hat in as wanting th= e above, but in
the interests of keeping things as simple as p= ossible, I kept myself out of
that level of change.

> What happens is that the previous victim did not = enter exit processing. If
> it would then it would be exclu= ded by other checks. The first victim never
> reacted and n= ever started using the memory resources available for=C2=A0
&g= t; exiting. Thats why I thought it maybe safe to go this way.
<= div class=3D"gmail_default" style=3D"">= >
> An issue could result from another process being ter= minated and the first
<= font face=3D"monospace, monospace">> victim finally reacting to the sign= al and also beginning termination. Then
> we have contentio= n on the reserves.
>

I do li= ke 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 TAS= K_UNINTERRUPTIBLE tasks
as low-hanging fruit and allowing the = oom to continue in the event that the
first attempt stalls?

Just a thought.
--001a113a8a1af1989c05200c3603-- -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org