linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Rientjes <rientjes@google.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Rik van Riel <riel@redhat.com>,
	linux-mm@kvack.org
Subject: [patch -mm 2/5 v2] oom: give current access to memory reserves if it has been killed
Date: Thu, 1 Apr 2010 12:44:31 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.00.1004011243020.13247@chino.kir.corp.google.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1004011240370.13247@chino.kir.corp.google.com>

It's possible to livelock the page allocator if a thread has mm->mmap_sem and 
fails to make forward progress because the oom killer selects another thread 
sharing the same ->mm to kill that cannot exit until the semaphore is dropped.

The oom killer will not kill multiple tasks at the same time; each oom killed 
task must exit before another task may be killed.  Thus, if one thread is 
holding mm->mmap_sem and cannot allocate memory, all threads sharing the same 
->mm are blocked from exiting as well.  In the oom kill case, that means the
thread holding mm->mmap_sem will never free additional memory since it cannot
get access to memory reserves and the thread that depends on it with access to
memory reserves cannot exit because it cannot acquire the semaphore.  Thus,
the page allocators livelocks.

When the oom killer is called and current happens to have a pending SIGKILL,
this patch automatically gives it access to memory reserves and returns.  Upon
returning to the page allocator, its allocation will hopefully succeed so it
can quickly exit and free its memory.  If not, the page allocator will fail
the allocation if it is not __GFP_NOFAIL.

Signed-off-by: David Rientjes <rientjes@google.com>
---
 mm/oom_kill.c |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/mm/oom_kill.c b/mm/oom_kill.c
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -679,6 +679,16 @@ void out_of_memory(struct zonelist *zonelist, gfp_t gfp_mask,
 		return;
 
 	/*
+	 * If current has a pending SIGKILL, then automatically select it.  The
+	 * goal is to allow it to allocate so that it may quickly exit and free
+	 * its memory.
+	 */
+	if (fatal_signal_pending(current)) {
+		set_tsk_thread_flag(current, TIF_MEMDIE);
+		return;
+	}
+
+	/*
 	 * Check if there were limitations on the allocation (only relevant for
 	 * NUMA) that may require different handling.
 	 */

--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2010-04-01 19:44 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-01 19:44 [patch -mm 0/5] oom: fixes and cleanup David Rientjes
2010-04-01 19:44 ` [patch -mm 1/5 v2] oom: hold tasklist_lock when dumping tasks David Rientjes
2010-04-02  0:38   ` KAMEZAWA Hiroyuki
2010-04-01 19:44 ` David Rientjes [this message]
2010-04-02  0:40   ` [patch -mm 2/5 v2] oom: give current access to memory reserves if it has been killed KAMEZAWA Hiroyuki
2010-04-01 19:44 ` [patch -mm 3/5] oom: avoid sending exiting tasks a SIGKILL David Rientjes
2010-04-02  0:41   ` KAMEZAWA Hiroyuki
2010-04-01 19:44 ` [patch -mm 4/5] oom: cleanup oom_kill_task David Rientjes
2010-04-02  0:42   ` KAMEZAWA Hiroyuki
2010-04-01 19:44 ` [patch -mm 5/5] oom: cleanup oom_badness David Rientjes
2010-04-02  0:44   ` KAMEZAWA Hiroyuki
2010-04-02  9:18     ` David Rientjes
2010-04-02 11:30 ` [patch -mm 0/5] oom: fixes and cleanup Oleg Nesterov
2010-04-05  7:36   ` KOSAKI Motohiro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.00.1004011243020.13247@chino.kir.corp.google.com \
    --to=rientjes@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-mm@kvack.org \
    --cc=oleg@redhat.com \
    --cc=riel@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox