linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Rientjes <rientjes@google.com>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	akpm@linux-foundation.org, caiqian@redhat.com, hughd@google.com,
	kamezawa.hiroyu@jp.fujitsu.com, minchan.kim@gmail.com,
	oleg@redhat.com
Subject: Re: [PATCH 4/5] oom: don't kill random process
Date: Mon, 23 May 2011 15:32:46 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.00.1105231529340.17840@chino.kir.corp.google.com> (raw)
In-Reply-To: <4DD6207E.1070300@jp.fujitsu.com>

On Fri, 20 May 2011, KOSAKI Motohiro wrote:

> CAI Qian reported oom-killer killed all system daemons in his
> system at first if he ran fork bomb as root. The problem is,
> current logic give them bonus of 3% of system ram. Example,
> he has 16GB machine, then root processes have ~500MB oom
> immune. It bring us crazy bad result. _all_ processes have
> oom-score=1 and then, oom killer ignore process memory usage
> and kill random process. This regression is caused by commit
> a63d83f427 (oom: badness heuristic rewrite).
> 
> This patch changes select_bad_process() slightly. If oom points == 1,
> it's a sign that the system have only root privileged processes or
> similar. Thus, select_bad_process() calculate oom badness without
> root bonus and select eligible process.
> 

You said earlier that you thought it was a good idea to do a proportional 
based bonus for root processes.  Do you have a specific objection to 
giving root processes a 1% bonus for every 10% of used memory instead?

> Also, this patch move finding sacrifice child logic into
> select_bad_process(). It's necessary to implement adequate
> no root bonus recalculation. and it makes good side effect,
> current logic doesn't behave as the doc.
> 

This is unnecessary and just makes the oom killer egregiously long.  We 
are already diagnosing problems here at Google where the oom killer holds 
tasklist_lock on the readside for far too long, causing other cpus waiting 
for a write_lock_irq(&tasklist_lock) to encounter issues when irqs are 
disabled and it is spinning.  A second tasklist scan is simply a 
non-starter.

 [ This is also one of the reasons why we needed to introduce
   mm->oom_disable_count to prevent a second, expensive tasklist scan. ]

> Documentation/sysctl/vm.txt says
> 
>     oom_kill_allocating_task
> 
>     If this is set to non-zero, the OOM killer simply kills the task that
>     triggered the out-of-memory condition.  This avoids the expensive
>     tasklist scan.
> 
> IOW, oom_kill_allocating_task shouldn't search sacrifice child.
> This patch also fixes this issue.
> 

oom_kill_allocating_task was introduced for SGI to prevent the expensive 
tasklist scan, the task that is actually allocating the memory isn't 
actually interesting and is usually random.  This should be turned into a 
documentation fix rather than changing the implementation.

Thanks.

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

  parent reply	other threads:[~2011-05-23 22:32 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-20  8:00 [PATCH v2 0/5] Fix oom killer doesn't work at all if system have > gigabytes memory (aka CAI founded issue) KOSAKI Motohiro
2011-05-20  8:01 ` [PATCH 1/5] oom: improve dump_tasks() show items KOSAKI Motohiro
2011-05-23 22:16   ` David Rientjes
2011-05-20  8:02 ` [PATCH 2/5] oom: kill younger process first KOSAKI Motohiro
2011-05-23  2:37   ` Minchan Kim
2011-05-23 22:20   ` David Rientjes
2011-05-20  8:03 ` [PATCH 3/5] oom: oom-killer don't use proportion of system-ram internally KOSAKI Motohiro
2011-05-23  3:59   ` Minchan Kim
2011-05-24  1:14     ` KOSAKI Motohiro
2011-05-24  1:32       ` Minchan Kim
2011-05-23  4:02   ` Minchan Kim
2011-05-24  1:44     ` KOSAKI Motohiro
2011-05-24  3:11       ` KOSAKI Motohiro
2011-05-23 22:28   ` David Rientjes
2011-05-23 22:48     ` David Rientjes
2011-05-24  1:21       ` KOSAKI Motohiro
2011-05-24  8:32       ` CAI Qian
2011-05-26  7:08       ` CAI Qian
2011-05-27 19:12         ` David Rientjes
2011-05-24  2:07     ` KOSAKI Motohiro
2011-05-26  9:34   ` CAI Qian
2011-05-26  9:56     ` KOSAKI Motohiro
2011-05-20  8:04 ` [PATCH 4/5] oom: don't kill random process KOSAKI Motohiro
2011-05-23  4:31   ` Minchan Kim
2011-05-24  1:53     ` KOSAKI Motohiro
2011-05-24  8:46       ` Minchan Kim
2011-05-24  8:49         ` KOSAKI Motohiro
2011-05-24  9:04           ` Minchan Kim
2011-05-24  9:09             ` KOSAKI Motohiro
2011-05-24  9:20               ` Minchan Kim
2011-05-24  9:38                 ` KOSAKI Motohiro
2011-05-23 22:32   ` David Rientjes [this message]
2011-05-24  1:35     ` KOSAKI Motohiro
2011-05-24  1:39       ` David Rientjes
2011-05-24  1:55         ` KOSAKI Motohiro
2011-05-24  1:58           ` David Rientjes
2011-05-24  2:03             ` KOSAKI Motohiro
2011-05-25 23:50               ` David Rientjes
2011-05-30  1:17                 ` KOSAKI Motohiro
2011-05-31  4:48                   ` David Rientjes
2011-05-31  4:54                     ` KOSAKI Motohiro
2011-05-20  8:05 ` [PATCH 5/5] oom: merge oom_kill_process() with oom_kill_task() KOSAKI Motohiro
2011-05-31  1:33 ` [PATCH v2 0/5] Fix oom killer doesn't work at all if system have > gigabytes memory (aka CAI founded issue) CAI Qian
2011-05-31  4:10   ` KOSAKI Motohiro
2011-05-31  4:14     ` CAI Qian
2011-05-31  4:34       ` KOSAKI Motohiro
2011-05-31  4:49       ` KOSAKI Motohiro
2011-05-31  4:32     ` KOSAKI Motohiro
2011-05-31  4:52     ` CAI Qian
2011-05-31  7:04       ` KOSAKI Motohiro
2011-05-31  7:50         ` CAI Qian
2011-05-31  7:56           ` KOSAKI Motohiro
2011-05-31  7:59             ` CAI Qian
2011-05-31  8:11               ` KOSAKI Motohiro
2011-05-31 10:01                 ` KOSAKI Motohiro
2011-06-01  1:17                   ` CAI Qian
2011-06-01  3:32                   ` Minchan Kim
2011-06-06  3:07                     ` KOSAKI Motohiro
2011-06-06 14:44                       ` 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.1105231529340.17840@chino.kir.corp.google.com \
    --to=rientjes@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=caiqian@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=minchan.kim@gmail.com \
    --cc=oleg@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