linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Rientjes <rientjes@google.com>
To: Andrea Arcangeli <aarcange@redhat.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Hugh Dickins <hugh.dickins@tiscali.co.uk>,
	vedran.furac@gmail.com,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Subject: Re: [PATCH] oom_kill: use rss value instead of vm size for badness
Date: Wed, 25 Nov 2009 13:39:59 -0800 (PST)	[thread overview]
Message-ID: <alpine.DEB.2.00.0911251334020.8191@chino.kir.corp.google.com> (raw)
In-Reply-To: <20091125124433.GB27615@random.random>

On Wed, 25 Nov 2009, Andrea Arcangeli wrote:

> You're focusing on the noise and not looking at the only thing that
> matters.
> 
> The noise level with rss went down to 50000, it doesn't matter the
> order of what's below 50000. Only thing it matters is the _delta_
> between "noise-level innocent apps" and "exploit".
> 
> The delta is clearly increase from 708945-max(noise) to
> 707878-max(noise) which translates to a increase of precision from
> 513250 to 665677, which shows how much more rss is making the
> detection more accurate (i.e. the distance between exploit and first
> innocent app). The lower level the noise level starts, the less likely
> the innocent apps are killed.
> 

That's not surprising since the amount of physical RAM is the constraining 
factor.

> There's simply no way to get to perfection, some innocent apps will
> always have high total_vm or rss levels, but this at least removes
> lots of innocent apps from the equation. The fact X isn't less
> innocent than before is because its rss is quite big, and this is not
> an error, luckily much smaller than the hog itself. Surely there are
> ways to force X to load huge bitmaps into its address space too
> (regardless of total_vm or rss) but again no perfection, just better
> with rss even in this testcase.
> 

We use the oom killer as a mechanism to enforce memory containment policy, 
we are much more interested in the oom killing priority than the oom 
killer's own heuristics to determine the ideal task to kill.  Those 
heuristics can't possibly represent the priorities for all possible 
workloads, so we require input from the user via /proc/pid/oom_adj to 
adjust that heuristic.  That has traditionally always used total_vm as a 
baseline which is a much more static value and can be quantified within a 
reasonable range by experimental data when it would not be defined as 
rogue.  By changing the baseline to rss, we lose much of that control 
since its more dynamic and dependent on the current state of the machine 
at the time of the oom which can be predicted with less accuracy.

--
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:[~2009-11-25 21:40 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-28  8:58 KAMEZAWA Hiroyuki
2009-10-28  9:15 ` David Rientjes
2009-10-28 11:04   ` KAMEZAWA Hiroyuki
2009-10-29  1:00     ` KAMEZAWA Hiroyuki
2009-10-29  2:31       ` Minchan Kim
2009-10-29  8:31       ` David Rientjes
2009-10-29  8:46         ` KAMEZAWA Hiroyuki
2009-10-29  9:01           ` David Rientjes
2009-10-29  9:16             ` KAMEZAWA Hiroyuki
2009-10-29  9:44               ` David Rientjes
2009-10-29 23:41                 ` KAMEZAWA Hiroyuki
2009-11-01 13:29         ` KOSAKI Motohiro
2009-11-02 10:42           ` David Rientjes
2009-11-02 12:35             ` KOSAKI Motohiro
2009-11-02 19:55               ` Vedran Furač
2009-11-03 23:09                 ` KOSAKI Motohiro
2009-11-07 19:16                   ` Vedran Furač
2009-11-25 12:44         ` Andrea Arcangeli
2009-11-25 21:39           ` David Rientjes [this message]
2009-11-27 18:26             ` Andrea Arcangeli
2009-11-30 23:09               ` David Rientjes
2009-12-01  4:43                 ` KOSAKI Motohiro
2009-12-01 22:20                   ` David Rientjes
2009-12-02  0:35                     ` KOSAKI Motohiro
2009-12-03 23:25                       ` David Rientjes
2009-12-04  0:44                         ` KAMEZAWA Hiroyuki
2009-11-26  0:10           ` Vedran Furač
2009-11-26  1:32             ` KAMEZAWA Hiroyuki
2009-11-27  1:56               ` Vedran Furač

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.0911251334020.8191@chino.kir.corp.google.com \
    --to=rientjes@google.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=hugh.dickins@tiscali.co.uk \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=vedran.furac@gmail.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