linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Rientjes <rientjes@google.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Hugh Dickins <hughd@google.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Andrey Vagin <avagin@openvz.org>,
	Frantisek Hrbata <fhrbata@redhat.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3 for 2.6.38] oom: oom_kill_process: fix the child_points logic
Date: Mon, 14 Mar 2011 13:41:43 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.00.1103141334470.31514@chino.kir.corp.google.com> (raw)
In-Reply-To: <20110314190530.GD21845@redhat.com>

On Mon, 14 Mar 2011, Oleg Nesterov wrote:

> oom_kill_process() starts with victim_points == 0. This means that
> (most likely) any child has more points and can be killed erroneously.
> 
> Also, "children has a different mm" doesn't match the reality, we
> should check child->mm != t->mm. This check is not exactly correct
> if t->mm == NULL but this doesn't really matter, oom_kill_task()
> will kill them anyway.
> 
> Note: "Kill all processes sharing p->mm" in oom_kill_task() is wrong
> too.
> 

There're two issues you're addressing in this patch.  It only kills a 
child in place of its selected parent when:

 - the child has a higher badness score, and

 - it has a different ->mm.

In the former case, NACK, we always want to sacrifice children regardless 
of their badness score (as long as it is non-zero) if it has a separate 
->mm in place of its parent, otherwise webservers will be killed instead 
of one of their children serving a client, sshd could be killed instead of 
bash, etc.  The behavior of the oom killer has always been to try to kill 
a child with its own ->mm first to avoid losing a large amount of work 
being done or unnecessarily killing a job scheduler, for example, when 
sacrificing a child would be satisfactory.  It'll kill additional tasks, 
and perhaps even the parent later if it has no more children, if the oom 
condition persists.

In the latter case, I agree, we should be testing if the child has a 
different ->mm before sacrificing it for its parent as the comment 
indicates it will.  I proposed that exact change in "oom: avoid deferring 
oom killer if exiting task is being traced" posted to -mm a couple days 
ago.

> Signed-off-by: Oleg Nesterov <oleg@redhat.com>
> ---
> 
>  mm/oom_kill.c |    3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> --- 38/mm/oom_kill.c~3_fix_kill_chld	2011-03-14 18:52:39.000000000 +0100
> +++ 38/mm/oom_kill.c	2011-03-14 19:36:01.000000000 +0100
> @@ -459,10 +459,10 @@ static int oom_kill_process(struct task_
>  			    struct mem_cgroup *mem, nodemask_t *nodemask,
>  			    const char *message)
>  {
> -	struct task_struct *victim = p;
> +	struct task_struct *victim;
>  	struct task_struct *child;
> -	struct task_struct *t = p;
> -	unsigned int victim_points = 0;
> +	struct task_struct *t;
> +	unsigned int victim_points;
>  
>  	if (printk_ratelimit())
>  		dump_header(p, gfp_mask, order, mem, nodemask);
> @@ -488,10 +488,15 @@ static int oom_kill_process(struct task_
>  	 * parent.  This attempts to lose the minimal amount of work done while
>  	 * still freeing memory.
>  	 */
> +	victim_points = oom_badness(p, mem, nodemask, totalpages);
> +	victim = p;
> +	t = p;
>  	do {
>  		list_for_each_entry(child, &t->children, sibling) {
>  			unsigned int child_points;
>  
> +			if (child->mm == t->mm)
> +				continue;
>  			/*
>  			 * oom_badness() returns 0 if the thread is unkillable
>  			 */
> 
> 

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2011-03-14 20:41 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-01 19:09 [patch] oom: prevent unnecessary oom kills or kernel panics David Rientjes
2011-03-03  1:20 ` KOSAKI Motohiro
2011-03-03 19:53   ` David Rientjes
2011-03-06 11:14     ` KOSAKI Motohiro
2011-03-06 22:06       ` David Rientjes
2011-03-08  0:24         ` KOSAKI Motohiro
2011-03-08  2:01         ` KOSAKI Motohiro
2011-03-08 13:42   ` Oleg Nesterov
2011-03-08 23:57     ` David Rientjes
2011-03-09 10:36       ` KOSAKI Motohiro
2011-03-09 11:06       ` Oleg Nesterov
2011-03-09 20:32         ` David Rientjes
2011-03-10 12:05           ` Oleg Nesterov
2011-03-10 15:40             ` [PATCH 0/1] Was: " Oleg Nesterov
2011-03-10 15:41               ` [PATCH 1/1] oom_kill_task: mark every thread as TIF_MEMDIE Oleg Nesterov
2011-03-13  1:08                 ` David Rientjes
2011-03-10 16:36               ` [PATCH 0/1] select_bad_process: improve the PF_EXITING check Oleg Nesterov
2011-03-10 16:37                 ` [PATCH 1/1] " Oleg Nesterov
2011-03-10 16:40                 ` [PATCH 0/1] " Oleg Nesterov
2011-03-10 17:18                   ` [PATCH v2 " Oleg Nesterov
2011-03-10 17:19                     ` [PATCH v2 1/1] " Oleg Nesterov
2011-03-13  1:06             ` [patch] oom: prevent unnecessary oom kills or kernel panics David Rientjes
2011-03-09 23:19       ` Andrew Morton
2011-03-11 19:45         ` David Rientjes
2011-03-12 12:34           ` Oleg Nesterov
2011-03-12 13:43             ` [PATCH 0/3] oom: TIF_MEMDIE/PF_EXITING fixes Oleg Nesterov
2011-03-12 13:44               ` [PATCH 1/3] oom: oom_kill_task: mark every thread as TIF_MEMDIE Oleg Nesterov
2011-03-13  1:14                 ` David Rientjes
2011-03-12 13:44               ` [PATCH 2/3] oom: select_bad_process: improve the PF_EXITING check Oleg Nesterov
2011-03-12 13:44               ` [PATCH 3/3] oom: select_bad_process: use same_thread_group() Oleg Nesterov
2011-03-12 19:40               ` [PATCH 0/3] oom: TIF_MEMDIE/PF_EXITING fixes Hugh Dickins
2011-03-13  8:53                 ` KOSAKI Motohiro
2011-03-13 21:27                 ` Oleg Nesterov
2011-03-14 19:04                   ` [PATCH 0/3 for 2.6.38] oom: fixes Oleg Nesterov
2011-03-14 19:04                     ` [PATCH 1/3 for 2.6.38] oom: oom_kill_process: don't set TIF_MEMDIE if !p->mm Oleg Nesterov
2011-03-14 19:35                       ` Linus Torvalds
2011-03-14 20:31                         ` Oleg Nesterov
2011-03-14 20:32                         ` David Rientjes
2011-03-15 19:12                           ` Oleg Nesterov
2011-03-15 19:51                             ` David Rientjes
2011-03-14 20:22                       ` David Rientjes
2011-03-15 18:53                         ` Oleg Nesterov
2011-03-15 19:54                           ` David Rientjes
2011-03-15 21:16                             ` Oleg Nesterov
2011-03-14 19:05                     ` [PATCH 2/3 for 2.6.38] oom: select_bad_process: ignore TIF_MEMDIE zombies Oleg Nesterov
2011-03-14 20:50                       ` David Rientjes
2011-03-14 19:05                     ` [PATCH 3/3 for 2.6.38] oom: oom_kill_process: fix the child_points logic Oleg Nesterov
2011-03-14 20:41                       ` David Rientjes [this message]
2011-03-15 19:21                         ` Oleg Nesterov
2011-03-13 11:36               ` [PATCH 0/3] oom: TIF_MEMDIE/PF_EXITING fixes KOSAKI Motohiro
2011-03-13  1:11             ` [patch] oom: prevent unnecessary oom kills or kernel panics David Rientjes
2011-03-13  1:15               ` [patch -mm] oom: avoid deferring oom killer if exiting task is being traced David Rientjes
2011-03-14 17:40                 ` Oleg Nesterov

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.1103141334470.31514@chino.kir.corp.google.com \
    --to=rientjes@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=avagin@openvz.org \
    --cc=fhrbata@redhat.com \
    --cc=hughd@google.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=oleg@redhat.com \
    --cc=torvalds@linux-foundation.org \
    /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