Memory overcommit

["Vedran Furač" <vedranf@vedranf.mine.nu>]

Hi! I don't know if this is appropriate place to ask such questions and
if not, please point me to such place.

Let's simulate a process gone berserk with this piece of code:

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <unistd.h>

int main()
{
  char *buf;
  while(1) {
    buf = malloc (1024*1024*100);
    if ( buf == NULL ) {
      perror("malloc");
      getchar();
      exit(EXIT_FAILURE);
    }
    sleep(1);
    memset(buf, 1, 1024*1024*100);
  }
  return 0;
}

# echo 0 > /proc/sys/vm/overcommit_memory

Compile, run and soon result is:
- System freezes for a second or two
- OOMK wakes up
- X crashes

Now, I'm back to VT1 and dmesg shows 8 process were killed by OOMK
(including X server and some long running daemons with small memory
footprint like automount) before the real culprit was killed. This
random killing spree *really* gives bad reputation to linux and people
usually point this out as an argument against it.

But, there is an easy fix:
# echo 2 > /proc/sys/vm/overcommit_memory
Run the program again and after a few seconds you'll get:

"malloc: Cannot allocate memory"

and that's all what happens. Nothing gets killed and one (and others
too) can continue to work without loosing time, data or both. Only
somewhat strange is that kernel contradicts itself when it says there is
no more and in the same time saying:

/proc/meminfo
MemTotal:        3542532 kB
MemFree:          892972 kB
Buffers:            2664 kB
Cached:           130940 kB

...that there is almost 900MB free memory. But OK, I can live with it.

So, my question is: why today overcommit isn't turned off *by default*?
I have it turned off for a few years now and only side effect is that I
don't get processes killed randomly anymore, I don't loose valuable time
and data.

Regards,

Vedran