From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754303AbbIRPlN (ORCPT ); Fri, 18 Sep 2015 11:41:13 -0400 Received: from resqmta-po-03v.sys.comcast.net ([96.114.154.162]:42132 "EHLO resqmta-po-03v.sys.comcast.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751659AbbIRPlM (ORCPT ); Fri, 18 Sep 2015 11:41:12 -0400 Date: Fri, 18 Sep 2015 10:41:09 -0500 (CDT) From: Christoph Lameter X-X-Sender: cl@east.gentwo.org To: Oleg Nesterov cc: Kyle Walker , 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 Subject: Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks In-Reply-To: <20150917192204.GA2728@redhat.com> Message-ID: References: <1442512783-14719-1-git-send-email-kwalker@redhat.com> <20150917192204.GA2728@redhat.com> Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > 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 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;