From: Andrea Arcangeli <aarcange@redhat.com>
To: David Rientjes <rientjes@google.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: Fri, 27 Nov 2009 19:26:07 +0100 [thread overview]
Message-ID: <20091127182607.GA30235@random.random> (raw)
In-Reply-To: <alpine.DEB.2.00.0911251334020.8191@chino.kir.corp.google.com>
On Wed, Nov 25, 2009 at 01:39:59PM -0800, David Rientjes wrote:
> 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.
Ok I can see the fact by being dynamic and less predictable worries
you. The "second to last" tasks especially are going to be less
predictable, but the memory hog would normally end up accounting for
most of the memory and this should increase the badness delta between
the offending tasks (or tasks) and the innocent stuff, so making it
more reliable. The innocent stuff should be more and more paged out
from ram. So I tend to think it'll be much less likely to kill an
innocent task this way (as demonstrated in practice by your
measurement too), but it's true there's no guarantee it'll always do
the right thing, because it's a heuristic anyway, but even total_vm
doesn't provide guarantee unless your workload is stationary and your
badness scores are fixed and no virtual memory is ever allocated by
any task in the system and no new task are spawned.
It'd help if you posted a regression showing smaller delta between
oom-target task and second task. My email was just to point out, your
measurement was a good thing in oom killing terms. If I've to imagine
the worst case for this, is an app allocating memory at very low
peace, and then slowly getting swapped out and taking huge swap
size. Maybe we need to add swap size to rss, dunno, but the paged out
MAP_SHARED equivalent can't be accounted like we can account swap
size, so in practice I feel a raw rss is going to be more practical
than making swap special vs file mappings.
--
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>
next prev parent reply other threads:[~2009-11-27 18:26 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
2009-11-27 18:26 ` Andrea Arcangeli [this message]
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=20091127182607.GA30235@random.random \
--to=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=rientjes@google.com \
--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