From: "Vedran Furač" <vedran.furac@gmail.com>
To: David Rientjes <rientjes@google.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: Sun, 31 Jan 2010 21:29:33 +0100 [thread overview]
Message-ID: <4B65E82D.5010408@gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1001301444480.16189@chino.kir.corp.google.com>
[-- Attachment #1: Type: text/plain, Size: 1709 bytes --]
David Rientjes wrote:
> On Sat, 30 Jan 2010, Vedran Furac wrote:
>
>>> The oom killer has been doing this for years and I haven't noticed a huge
>>> surge in complaints about it killing X specifically because of that code
>>> in oom_kill_process().
>> Well you said it yourself, you won't see a surge because "oom killer has
>> been doing this *for years*". So you'll have a more/less constant number
>> of complains over the years. Just google for: linux, random, kill, memory;
>
> 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.
> The facts that you're completely ignoring are that changing the heuristic
> baseline to rss is not going to prevent Xorg or sshd from being selected
In my tests a simple "ps -eo rss,command --sort rss" always showed the
cuprit, but OK, find another approach in fixing the problem in hope for
a positive review. Just... I feel everything will be put under the
carpet with fingers in ears while singing everything is fine. Prove me
wrong.
Regards,
Vedran
--
http://vedranf.net | a8e7a7783ca0d460fee090cc584adc12
[-- Attachment #2: vedran_furac.vcf --]
[-- Type: text/x-vcard, Size: 220 bytes --]
begin:vcard
fn;quoted-printable:Vedran Fura=C4=8D
n;quoted-printable:Fura=C4=8D;Vedran
adr:;;;;;;Croatia
email;internet:vedran.furac@gmail.com
x-mozilla-html:FALSE
url:http://vedranf.net
version:2.1
end:vcard
next prev parent reply other threads:[~2010-01-31 20:29 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-29 16:11 [PATCH v3] oom-kill: add lowmem usage aware oom kill handling 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č [this message]
2010-02-01 10:33 ` David Rientjes
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=4B65E82D.5010408@gmail.com \
--to=vedran.furac@gmail.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=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;
as well as URLs for NNTP newsgroup(s).