From: David Rientjes <rientjes@google.com>
To: Vedran Furac <vedran.furac@gmail.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Andrew Morton <akpm@linux-foundation.org>,
minchan.kim@gmail.com, Balbir Singh <balbir@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH v3] oom-kill: add lowmem usage aware oom kill handling
Date: Mon, 1 Feb 2010 02:33:55 -0800 (PST) [thread overview]
Message-ID: <alpine.DEB.2.00.1002010228360.12764@chino.kir.corp.google.com> (raw)
In-Reply-To: <4B65E82D.5010408@gmail.com>
On Sun, 31 Jan 2010, Vedran Furac wrote:
> > You snipped the code segment where I demonstrated that the selected task
> > for oom kill is not necessarily the one chosen to die: if there is a child
> > with disjoint memory that is killable, it will be selected instead. If
> > Xorg or sshd is being chosen for kill, then you should investigate why
> > that is, but there is nothing random about how the oom killer chooses
> > tasks to kill.
>
> I know that it isn't random, but it sure looks like that to the end user
> and I use it to emphasize the problem. And about me investigating, that
> simply not possible as I am not a kernel hacker who understands the code
> beyond the syntax level. I can only point to the problem in hope that
> someone will fix it.
>
Disregarding the opportunity that userspace has to influence the oom
killer's selection for a moment, it really tends to favor killing tasks
that are the largest in size. Tasks that typically get the highest
badness score are those that have the highest mm->total_vm, it's that
simple. There are definitely cornercases where the first generation
children have a strong influence, but they are often killed either as a
result of themselves being a thread group leader with seperate memory from
the parent or as the result of the oom killer killing a task with seperate
memory before the selected task. It's completely natural for the oom
killer to select bash, for example, when in actuality it will kill a
memory leaker that has a high badness score as a result of the logic in
oom_kill_process().
If you have specific logs that you'd like to show, please enable
/proc/sys/vm/oom_dump_tasks and respond with them in another message with
that data inline.
--
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-01 10:34 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-29 16:11 KAMEZAWA Hiroyuki
2010-01-29 16:21 ` Alan Cox
2010-01-29 16:25 ` KAMEZAWA Hiroyuki
2010-01-29 16:30 ` Alan Cox
2010-01-29 16:41 ` KAMEZAWA Hiroyuki
2010-01-29 21:07 ` David Rientjes
2010-01-30 12:46 ` Vedran Furač
2010-01-30 22:53 ` David Rientjes
2010-01-31 20:29 ` Vedran Furač
2010-02-01 10:33 ` David Rientjes [this message]
2010-02-01 0:01 ` KAMEZAWA Hiroyuki
2010-02-01 10:28 ` David Rientjes
2010-01-29 21:11 ` David Rientjes
-- strict thread matches above, loose matches on Subject: below --
2010-01-21 5:59 [PATCH] " KAMEZAWA Hiroyuki
2010-01-22 6:23 ` [PATCH v2] " KAMEZAWA Hiroyuki
2010-01-25 6:15 ` [PATCH v3] " KAMEZAWA Hiroyuki
2010-01-26 23:12 ` Andrew Morton
2010-01-26 23:53 ` KAMEZAWA Hiroyuki
2010-01-27 0:19 ` Andrew Morton
2010-01-27 0:58 ` KAMEZAWA Hiroyuki
2010-01-27 23:56 ` David Rientjes
2010-01-28 0:16 ` Alan Cox
2010-01-28 0:26 ` KAMEZAWA Hiroyuki
2010-01-28 0:59 ` David Rientjes
2010-01-29 0:25 ` Vedran Furač
2010-01-29 0:35 ` Alan Cox
2010-01-29 0:57 ` Vedran Furač
2010-01-29 11:03 ` Alan Cox
2010-01-30 12:33 ` Vedran Furač
2010-01-30 12:59 ` Alan Cox
2010-01-30 17:30 ` Vedran Furač
2010-01-30 17:45 ` Alan Cox
2010-01-30 18:17 ` Vedran Furač
2010-01-27 23:46 ` David Rientjes
2010-01-26 23:16 ` Andrew Morton
2010-01-26 23:44 ` KAMEZAWA Hiroyuki
2010-01-27 23:40 ` 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=alpine.DEB.2.00.1002010228360.12764@chino.kir.corp.google.com \
--to=rientjes@google.com \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=balbir@linux.vnet.ibm.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan.kim@gmail.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