From: "Vedran Furač" <vedran.furac@gmail.com>
To: David Rientjes <rientjes@google.com>
Cc: Hugh Dickins <hugh.dickins@tiscali.co.uk>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
minchan.kim@gmail.com, Andrew Morton <akpm@linux-foundation.org>,
Andrea Arcangeli <aarcange@redhat.com>
Subject: Re: Memory overcommit
Date: Mon, 02 Nov 2009 20:56:41 +0100 [thread overview]
Message-ID: <4AEF3979.9090306@gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.00.0910301232180.1090@chino.kir.corp.google.com>
David Rientjes wrote:
> On Fri, 30 Oct 2009, Vedran Furac wrote:
>
>> Well, you are kernel hacker, not me. You know how linux mm works much
>> more than I do. I just reported a, what I think is a big problem, which
>> needs to be solved ASAP (2.6.33).
>
> The oom killer heuristics have not been changed recently, why is this
> suddenly a problem that needs to be immediately addressed? The heuristics
> you've been referring to have been used for at least three years.
It isn't "suddenly a problem", but only a problem, big long time
problem. If it is three years old, then it should have been addressed
asap three years ago (and we would not need to talk about it now,
hopefully).
> However, I don't think we can simply change the baseline (like the rss
> change which has been added to -mm (??)) and consider it a major
> improvement when it severely impacts how system administrators are able to
> tune the badness heuristic from userspace via /proc/pid/oom_adj. I'm sure
> you'd agree that user input is important in this matter and so that we
> should maximize that ability rather than make it more difficult. That's
> my main criticism of the suggestions thus far (and, sorry, but I have to
> look out for production server interests here: you can't take away our
> ability to influence oom badness scoring just because other simple
> heuristics may be more understandable).
>
> What would be better, and what I think we'll end up with, is a root
> selectable heuristic so that production servers and desktop machines can
> use different heuristics to make oom kill selections. We already have
> /proc/sys/vm/oom_kill_allocating_task which I added 1-2 years ago to
> address concerns specifically of SGI and their enormously long tasklist
> scans. This would be variation on that idea and would include different
> simplistic behaviors (such as always killing the most memory hogging task,
> killing the most recently started task by the same uid, etc), and leave
> the default heuristic much the same as currently.
OK, agreed. Did you take a look at the set of patches Kame sent today?
Regards,
Vedran
--
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-02 19:56 UTC|newest]
Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <hav57c$rso$1@ger.gmane.org>
[not found] ` <20091013120840.a844052d.kamezawa.hiroyu@jp.fujitsu.com>
[not found] ` <hb2cfu$r08$2@ger.gmane.org>
[not found] ` <20091014135119.e1baa07f.kamezawa.hiroyu@jp.fujitsu.com>
2009-10-20 21:52 ` Vedran Furač
2009-10-26 1:55 ` KAMEZAWA Hiroyuki
2009-10-26 16:16 ` Vedran Furač
2009-10-27 3:22 ` KAMEZAWA Hiroyuki
2009-10-27 6:10 ` KOSAKI Motohiro
2009-10-27 6:34 ` Minchan Kim
2009-10-27 6:36 ` KAMEZAWA Hiroyuki
2009-10-27 6:55 ` Minchan Kim
2009-10-27 7:45 ` [RFC][PATCH] oom_kill: avoid depends on total_vm and use real RSS/swap value for oom_score (Re: " KAMEZAWA Hiroyuki
2009-10-27 7:56 ` Minchan Kim
2009-10-27 12:38 ` Andrea Arcangeli
2009-10-28 0:22 ` KAMEZAWA Hiroyuki
2009-10-28 0:45 ` Vedran Furač
2009-10-27 7:56 ` KAMEZAWA Hiroyuki
2009-10-27 8:14 ` Minchan Kim
2009-10-27 8:33 ` KAMEZAWA Hiroyuki
2009-10-27 8:52 ` Minchan Kim
2009-10-27 8:56 ` KAMEZAWA Hiroyuki
2009-10-27 17:41 ` Vedran Furač
2009-10-28 0:13 ` KAMEZAWA Hiroyuki
2009-10-27 18:39 ` Hugh Dickins
2009-10-27 18:47 ` Andrea Arcangeli
2009-10-28 0:32 ` KAMEZAWA Hiroyuki
2009-11-05 19:02 ` Pavel Machek
2009-10-28 0:28 ` KAMEZAWA Hiroyuki
2009-10-27 6:46 ` KOSAKI Motohiro
2009-10-27 6:56 ` Minchan Kim
2009-10-27 17:12 ` Vedran Furač
2009-10-27 18:02 ` KOSAKI Motohiro
2009-10-27 18:30 ` Vedran Furač
2009-10-27 20:44 ` Hugh Dickins
2009-10-27 21:04 ` David Rientjes
2009-10-28 0:08 ` Vedran Furač
2009-10-28 0:25 ` David Rientjes
2009-10-28 0:39 ` Vedran Furač
2009-10-28 4:08 ` David Rientjes
2009-10-28 4:55 ` KAMEZAWA Hiroyuki
2009-10-28 5:13 ` David Rientjes
2009-10-28 6:05 ` KAMEZAWA Hiroyuki
2009-10-28 6:17 ` David Rientjes
2009-10-28 6:20 ` KAMEZAWA Hiroyuki
2009-10-29 8:38 ` David Rientjes
2009-10-29 11:11 ` Vedran Furač
2009-10-29 19:53 ` David Rientjes
2009-10-29 23:48 ` KAMEZAWA Hiroyuki
2009-10-30 9:10 ` David Rientjes
2009-10-30 9:36 ` KAMEZAWA Hiroyuki
2009-11-03 20:49 ` David Rientjes
2009-11-04 0:50 ` KAMEZAWA Hiroyuki
2009-11-04 1:58 ` David Rientjes
2009-11-04 2:17 ` KAMEZAWA Hiroyuki
2009-11-04 3:10 ` David Rientjes
2009-11-04 3:19 ` KAMEZAWA Hiroyuki
2009-10-30 13:59 ` Vedran Furač
2009-10-30 19:24 ` David Rientjes
2009-11-02 19:58 ` Vedran Furač
2009-10-28 13:28 ` Vedran Furač
2009-10-28 20:10 ` David Rientjes
2009-10-29 3:05 ` Vedran Furač
2009-10-29 8:35 ` David Rientjes
2009-10-29 11:01 ` Vedran Furač
2009-10-29 19:42 ` David Rientjes
2009-10-30 13:53 ` Vedran Furač
2009-10-30 14:08 ` Thomas Fjellstrom
2009-10-30 15:13 ` Vedran Furač
2009-10-30 14:12 ` Andrea Arcangeli
2009-10-30 14:41 ` Vedran Furač
2009-10-30 15:15 ` Andrea Arcangeli
2009-10-30 16:24 ` Hugh Dickins
2009-11-02 19:56 ` Vedran Furač
2009-10-30 19:44 ` David Rientjes
2009-11-02 19:56 ` Vedran Furač [this message]
2009-10-28 0:43 ` KAMEZAWA Hiroyuki
2009-10-28 2:47 ` KOSAKI Motohiro
2009-10-28 3:17 ` KAMEZAWA Hiroyuki
2009-10-28 4:12 ` David Rientjes
2009-10-28 8:10 ` Hugh Dickins
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=4AEF3979.9090306@gmail.com \
--to=vedran.furac@gmail.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=minchan.kim@gmail.com \
--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