From: Lubos Lunak <l.lunak@suse.cz>
To: balbir@linux.vnet.ibm.com
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
David Rientjes <rientjes@google.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Nick Piggin <npiggin@suse.de>, Jiri Kosina <jkosina@suse.cz>
Subject: Re: Improving OOM killer
Date: Wed, 3 Feb 2010 13:10:27 +0100 [thread overview]
Message-ID: <201002031310.28271.l.lunak@suse.cz> (raw)
In-Reply-To: <20100203085711.GF19641@balbir.in.ibm.com>
On Wednesday 03 of February 2010, Balbir Singh wrote:
> * Lubos Lunak <l.lunak@suse.cz> [2010-02-01 23:02:37]:
> > In other words, use VmRSS for measuring memory usage instead of VmSize,
> > and remove child accumulating.
>
> I am not sure of the impact of changing to RSS, although I've
> personally believed that RSS based accounting is where we should go,
> but we need to consider the following
>
> 1. Total VM provides data about potentially swapped pages,
Yes, I've already updated my proposal in another mail to switch from VmSize
to VmRSS+InSwap. I don't know how to find out the second item in code, but at
this point of discussion that's just details.
> overcommit,
I don't understand how this matters. Overcommit is memory for which address
space has been allocated but not actual memory, right? Then that's exactly
what I'm claiming is wrong and am trying to reverse. Currently OOM killer
takes this into account because it uses VmSize, but IMO it shouldn't - if a
process does malloc(400M) but then it uses only a tiny fraction of that, in
the case of memory shortage killing that process does not solve anything in
practice.
> etc.
> 2. RSS alone is not sufficient, RSS does not account for shared pages,
> so we ideally need something like PSS.
Just to make sure I understand what you mean with "RSS does not account for
shared pages" - you say that if a page is shared by 4 processes, then when
calculating badness for them, only 1/4 of the page should be counted for
each? Yes, I suppose so, that makes sense. That's more like fine-tunning at
this point though, as long as there's no agreement that moving away from
VmSize is an improvement.
> I suspect the correct answer would depend on our answers to 1 and 2
> and a lot of testing with any changes made.
Testing - are there actually any tests for it, or do people just test random
scenarios when they do changes? Also, I'm curious, what areas is the OOM
killer actually generally known to work well in? I somehow get the feeling
from the discussion here that people just tweak oom_adj until it works for
them.
--
Lubos Lunak
openSUSE Boosters team, KDE developer
l.lunak@suse.cz , l.lunak@kde.org
--
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:[~2010-02-03 12:10 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-01 22:02 Lubos Lunak
2010-02-01 23:53 ` David Rientjes
2010-02-02 21:10 ` Lubos Lunak
2010-02-03 1:41 ` David Rientjes
2010-02-03 1:52 ` KAMEZAWA Hiroyuki
2010-02-03 2:12 ` David Rientjes
2010-02-03 2:12 ` KAMEZAWA Hiroyuki
2010-02-03 2:36 ` [patch] sysctl: clean up vm related variable declarations David Rientjes
2010-02-03 8:07 ` KOSAKI Motohiro
2010-02-03 8:17 ` Balbir Singh
2010-02-03 22:54 ` Improving OOM killer Lubos Lunak
2010-02-04 0:00 ` David Rientjes
2010-02-03 7:50 ` KOSAKI Motohiro
2010-02-03 9:40 ` David Rientjes
2010-02-03 8:57 ` Balbir Singh
2010-02-03 12:10 ` Lubos Lunak [this message]
2010-02-03 12:25 ` Balbir Singh
2010-02-03 15:00 ` Minchan Kim
2010-02-03 16:06 ` Minchan Kim
2010-02-03 21:22 ` Lubos Lunak
2010-02-03 14:49 ` Rik van Riel
2010-02-03 17:01 ` Balbir Singh
2010-02-03 18:58 ` David Rientjes
2010-02-03 19:29 ` Frans Pop
2010-02-03 19:52 ` David Rientjes
2010-02-03 20:12 ` Frans Pop
2010-02-03 20:26 ` David Rientjes
2010-02-03 22:55 ` Lubos Lunak
2010-02-04 0:05 ` David Rientjes
2010-02-04 0:18 ` Rik van Riel
2010-02-04 21:48 ` David Rientjes
2010-02-04 22:06 ` Rik van Riel
2010-02-04 22:14 ` David Rientjes
2010-02-10 20:54 ` Lubos Lunak
2010-02-10 21:10 ` Rik van Riel
2010-02-10 21:29 ` Lubos Lunak
2010-02-10 22:18 ` Alan Cox
2010-02-10 22:31 ` David Rientjes
2010-02-11 9:50 ` Lubos Lunak
2010-02-04 22:31 ` Frans Pop
2010-02-04 22:53 ` David Rientjes
2010-02-04 7:58 ` Lubos Lunak
2010-02-04 21:34 ` David Rientjes
2010-02-10 20:54 ` Lubos Lunak
2010-02-10 21:09 ` Rik van Riel
2010-02-10 21:34 ` Lubos Lunak
2010-02-10 22:25 ` David Rientjes
2010-02-11 10:16 ` Lubos Lunak
2010-02-11 21:17 ` David Rientjes
2010-02-04 9:50 ` Jiri Kosina
2010-02-04 21:39 ` David Rientjes
2010-02-05 7:35 ` Oliver Neukum
2010-02-10 3:10 ` David Rientjes
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=201002031310.28271.l.lunak@suse.cz \
--to=l.lunak@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=balbir@linux.vnet.ibm.com \
--cc=jkosina@suse.cz \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=npiggin@suse.de \
--cc=rientjes@google.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