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

From: Willy TARREAU
Date: Fri Dec 30 2005 - 16:46:13 EST


On Fri, Dec 30, 2005 at 11:51:58PM +0300, Al Boldi wrote:
> Barry K. Nathan wrote:
> > On 12/30/05, Al Boldi <a1426z@xxxxxxxxx> wrote:
> > > Thanks a lot!
> > >
> > > > +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.
> >
> > I think you can get paranoid overcommit with either my patch or 2.6 by
> > setting /proc/sys/vm/overcommit_mode to 2 *and*
> > /proc/sys/vm/overcommit_ratio to 0, however.
>
> Not really in 2.6.
> And even if this were made to work, what would it imply to a system running
> w/o swap?

I can clearly reply on this one :

root@pcw:vm# swapoff -a
root@pcw:vm# free
total used free shared buffers cached
Mem: 1031752 84992 946760 0 3144 38564
-/+ buffers/cache: 43284 988468
Swap: 0 0 0
root@pcw:vm# echo 2 > overcommit_memory
root@pcw:vm# echo 0 > overcommit_ratio
root@pcw:vm# uname -a
bash: fork: Cannot allocate memory
root@pcw:vm# echo 10 > overcommit_ratio
root@pcw:vm# uname -a
Linux pcw 2.4.33-pre1 #1 SMP Fri Dec 30 21:52:06 CET 2005 i686 unknown
root@pcw:vm#

So as one could expect, if you're limited to allocation of
(swap_size)+0% of RAM, then you have a limit of 0 kB, so that
malloc() always fails. I'll do some crash tests with mmap, shm
and 100 ratio to see how it behaves, but at the moment it's
clearly good. Multi-process malloc cannot allocate more than
specified and that's good.

> Thanks!
>
> --
> Al

Regards,
Willy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/