linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Rientjes <rientjes@google.com>
To: Minchan Kim <minchan.kim@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Nick Piggin <npiggin@suse.de>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH -mm] Kill existing current task quickly
Date: Tue, 16 Feb 2010 14:03:10 -0800 (PST)	[thread overview]
Message-ID: <alpine.DEB.2.00.1002161357170.23037@chino.kir.corp.google.com> (raw)
In-Reply-To: <1266335957.1709.67.camel@barrios-desktop>

On Wed, 17 Feb 2010, Minchan Kim wrote:

> If we found current task is existing but didn't set TIF_MEMDIE
> during OOM victim selection, let's stop unnecessary looping for
> getting high badness score task and go ahead for killing current.
> 
> This patch would make side effect skip OOM_DISABLE test.
> But It's okay since the task is existing and oom_kill_process
> doesn't show any killing message since __oom_kill_task will
> interrupt it in oom_kill_process.
> 
> Signed-off-by: Minchan Kim <minchan.kim@gmail.com>
> Cc: Nick Piggin <npiggin@suse.de>
> ---
>  mm/oom_kill.c |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index 3618be3..5c21398 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -295,6 +295,7 @@ static struct task_struct
> *select_bad_process(unsigned long *ppoints,
>  
>  			chosen = p;
>  			*ppoints = ULONG_MAX;
> +			break;
>  		}
>  
>  		if (p->signal->oom_adj == OOM_DISABLE)

No, we don't want to break because there may be other candidate tasks that 
have TIF_MEMDIE set that will be detected if we keep scanning.  Returning 
ERR_PTR(-1UL) from select_bad_process() has a special meaning: it means we 
return to the page allocator without doing anything.  We don't want more 
than one candidate task to ever have TIF_MEMDIE at a time, otherwise they 
can deplete all memory reserves and not make any forward progress.  So we 
always have to iterate the entire tasklist unless we find an already oom 
killed task with access to memory reserves (to prevent needlessly killing 
additional tasks before the first had a chance to exit and free its 
memory) or a different candidate task is exiting so we'll be freeing 
memory shortly (or it will be invoking the oom killer itself as current 
and then get chosen as the victim).

--
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>

  reply	other threads:[~2010-02-16 22:03 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-16 15:59 Minchan Kim
2010-02-16 22:03 ` David Rientjes [this message]
2010-02-17  6:26   ` Minchan Kim
2010-02-17  9:36     ` David Rientjes
2010-02-17 10:55       ` Minchan Kim

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.1002161357170.23037@chino.kir.corp.google.com \
    --to=rientjes@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=minchan.kim@gmail.com \
    --cc=npiggin@suse.de \
    /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