lkml.org 
[lkml]   [2010]   [Nov]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] Revert oom rewrite series
Date
> 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.

Why?
You actually got the bug report.


>
> > > > 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.

No. I dislike. I dislike propotinal score.



\
 
 \ /
  Last update: 2010-11-30 14:07    [W:0.127 / U:0.336 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site