From: David Rientjes <rientjes@google.com>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
Ying Han <yinghan@google.com>, Bodo Eggert <7eggert@web.de>,
Mandeep Singh Baines <msb@google.com>,
"Figo.zhang" <figo1802@gmail.com>
Subject: Re: [PATCH] Revert oom rewrite series
Date: Sat, 27 Nov 2010 17:45:36 -0800 (PST) [thread overview]
Message-ID: <alpine.DEB.2.00.1011271743180.3764@chino.kir.corp.google.com> (raw)
In-Reply-To: <20101123151731.7B7B.A69D9226@jp.fujitsu.com>
On Tue, 23 Nov 2010, KOSAKI Motohiro wrote:
> > You may remember that the initial version of my rewrite replaced oom_adj
> > entirely with the new oom_score_adj semantics. Others suggested that it
> > be seperated into a new tunable and the old tunable deprecated for a
> > lengthy period of time. I accepted that criticism and understood the
> > drawbacks of replacing the tunable immediately and followed those
> > suggestions. I disagree with you that the deprecation of oom_adj for a
> > period of two years is as dramatic as you imply and I disagree that users
> > are experiencing problems with the linear scale that it now operates on
> > versus the old exponential scale.
>
> Yes and No. People wanted to separate AND don't break old one.
>
You're arguing on the behalf of applications that don't exist.
> > > 1) About two month ago, Dave hansen observed strange OOM issue because he
> > > has a big machine and ALL process are not so big. thus, eventually all
> > > process got oom-score=0 and oom-killer didn't work.
> > >
> > > https://kerneltrap.org/mailarchive/linux-driver-devel/2010/9/9/6886383
> > >
> > > DavidR changed oom-score to +1 in such situation.
> > >
> > > http://kerneltrap.org/mailarchive/linux-kernel/2010/9/9/4617455
> > >
> > > But it is completely bognus. If all process have score=1, oom-killer fall
> > > back to purely random killer. I expected and explained his patch has
> > > its problem at half years ago. but he didn't fix yet.
> > >
> >
> > The resolution with which the oom killer considers memory is at 0.1% of
> > system RAM at its highest (smaller when you have a memory controller,
> > cpuset, or mempolicy constrained oom). It considers a task within 0.1% of
> > memory of another task to have equal "badness" to kill, we don't break
> > ties in between that resolution -- it all depends on which one shows up in
> > the tasklist first. If you disagree with that resolution, which I support
> > as being high enough, then you may certainly propose a patch to make it
> > even finer at 0.01%, 0.001%, etc. It would only change oom_badness() to
> > range between [0,10000], [0,100000], etc.
>
> No.
> Think Moore's Law. rational value will be not able to work in future anyway.
> 10 years ago, I used 20M bytes memory desktop machine and I'm now using 2GB.
> memory amount is growing and growing. and bash size doesn't grwoing so fast.
>
If you'd like to suggest an increase to the upper-bound of the badness
score, please do so, although I don't think we need to break ties amongst
tasks that differ by at most <0.1% of the system's capacity.
next prev parent reply other threads:[~2010-11-28 1:45 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-14 5:07 [PATCH] Revert oom rewrite series KOSAKI Motohiro
2010-11-14 19:32 ` Linus Torvalds
2010-11-15 0:54 ` KOSAKI Motohiro
2010-11-15 2:19 ` Andrew Morton
[not found] ` <AANLkTik_SDaiu2eQsJ9+4ywLR5K5V1Od-hwop6gwas3F@mail.gmail.com>
2010-11-15 4:41 ` Figo.zhang
2010-11-15 6:57 ` KOSAKI Motohiro
2010-11-15 10:34 ` David Rientjes
2010-11-15 23:31 ` Jesper Juhl
2010-11-16 0:06 ` David Rientjes
2010-11-16 10:04 ` Martin Knoblauch
2010-11-16 10:33 ` Alessandro Suardi
2010-11-16 0:13 ` Valdis.Kletnieks
2010-11-16 6:43 ` David Rientjes
2010-11-16 11:03 ` Alan Cox
2010-11-16 13:03 ` Florian Mickler
2010-11-16 14:55 ` Alan Cox
2010-11-16 20:57 ` David Rientjes
2010-11-16 21:01 ` Fabio Comolli
2010-11-17 4:04 ` Valdis.Kletnieks
2010-11-16 15:15 ` Alejandro Riveira Fernández
2010-11-23 7:16 ` KOSAKI Motohiro
2010-11-28 1:45 ` David Rientjes [this message]
2010-11-30 13:04 ` KOSAKI Motohiro
2010-11-30 20:02 ` David Rientjes
2010-11-23 7:16 ` KOSAKI Motohiro
2010-11-23 23:51 ` KOSAKI Motohiro
2010-11-14 21:58 ` David Rientjes
2010-11-15 23:33 ` Bodo Eggert
2010-11-15 23:50 ` David Rientjes
2010-11-17 0:06 ` Bodo Eggert
2010-11-17 0:25 ` David Rientjes
2010-11-17 0:48 ` Mandeep Singh Baines
-- strict thread matches above, loose matches on Subject: below --
2010-11-10 15:14 [PATCH v3]mm/oom-kill: direct hardware access processes should get bonus Figo.zhang
2010-11-10 15:24 ` Figo.zhang
2010-11-14 5:21 ` KOSAKI Motohiro
2010-11-14 21:33 ` David Rientjes
2010-11-15 3:26 ` [PATCH] Revert oom rewrite series Figo.zhang
2010-11-15 10:14 ` David Rientjes
2010-11-15 10:57 ` Alan Cox
2010-11-15 20:54 ` David Rientjes
2010-11-23 7:16 ` KOSAKI Motohiro
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.1011271743180.3764@chino.kir.corp.google.com \
--to=rientjes@google.com \
--cc=7eggert@web.de \
--cc=akpm@linux-foundation.org \
--cc=figo1802@gmail.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=msb@google.com \
--cc=torvalds@linux-foundation.org \
--cc=yinghan@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).