Re: [PATCH] strict VM overcommit accounting for 2.4.32/2.4.33-pre1

[Willy Tarreau <willy@w.ods.org>]

On Sat, Dec 31, 2005 at 07:59:02AM +0300, Al Boldi wrote:
> Alan Cox wrote:
> > On Gwe, 2005-12-30 at 23:06 +0300, Al Boldi wrote:
> > > > +3 - (NEW) paranoid overcommit The total address space commit
> > > > +      for the system is not permitted to exceed swap. The machine
> > > > +      will never kill a process accessing pages it has mapped
> > > > +      except due to a bug (ie report it!)
> > >
> > > This one isn't in 2.6, which is critical for a stable system.
> >
> > Actually it is
> >
> > In the 2.4 case we took  "50% RAM + swap" as the safe sane world 'never
> > OOM kill' and to all intents and purposes it works. We also had a 100%
> > paranoia mode.
> >
> > When it was ported to 2.6 (not by me) whoever did it very sensibly made
> > the percentage tunable and removed "mode 3" since its mode 2 0% ram and
> > can be set that way.
> 
> Only, doesn't this imply that you cannot control overcommit unless backed by 
> swap?  i.e Without swap the kernel cannot use all of ram, because it would 
> overcommit no-matter what, thus invoking OOM-killer.
> 
> Which raises an important question:  What's overcommit to do with limiting 
> access to physical RAM?

As shown in my previous mail, it allows malloc() to return NULL. I've
also successfully verified that it allows mmap() to fail if there is
not enough memory. I disabled swap, and set the overcommit_ratio to 95
and could not kill the system. Above this, it becomes tricky. At 97, I
see the last malloc() calls take a very long time, and at 98, the
system still hangs. But 95% without swap seems stable here.

> Thanks!
> 
> --
> Al

Cheers,
Willy