Re: additional oom-killer tuneable worth submitting?

[Alan <alan@lxorguk.ukuu.org.uk>]

On Fri, 8 Dec 2006 16:58:29 +0300
Al Boldi <a1426z@gawab.com> wrote:
> > That is why we have no-overcommit support.
> 
> Alan, I think you know that this isn't really true, due to shared-libs.

Shared libraries are correctly handled by no-overcommit and in fact they
have almost zero impact on out of memory questions because the shared
parts of the library are file backed and constant. That means they don't
actually cost swap space.

> > Now there is an argument for
> > a meaningful rlimit-as to go with it, and together I think they do what
> > you really need.
> 
> The problem with rlimit is that it works per process.  Tuning this by hand 
> may be awkward and/or wasteful.  What we need is to rlimit on a global 
> basis, by calculating an upperlimit dynamically, such as to avoid 
> overcommit/OOM.

You've just described the existing no overcommit functionality, although
you've forgotten to allow for pre-reserving of stacks and some other
detail that has been found to make it work better as it has been refined.

Alan