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