I know about memory overcommitment and I profoundly dislike it and usually disable it.
A well written program could
mmap which is often used by
malloc) more memory than available and crash when using it. Without memory overcommitment, that
mmap would fail and the well written program would catch that failure. The poorly written program (using
malloc without checks against failure) would crash when using the result of a failed
Of course virtual address space (which gets extended by
mmap so by
malloc) is not the same as RAM (RAM is a resource managed by the kernel, see this; processes have their virtual address space initialized by execve(2) and extended by
sbrk so don't consume directly RAM, only virtual memory).
Notice that optimizing RAM usage could be done with madvise(2) (which could give a hint, using
MADV_DONTNEED to the kernel to swap some pages onto the disk), when really needed. Programs wanting some overcommitment could use mmap(2) with
MAP_NORESERVE. My understanding of memory overcommitment is as if every memory mapping (by
mmap) is using implicitly
My perception of it is that it is simply useful for very buggy programs. But IMHO a real developer should always check failure of
mmap and related virtual address space changing functions (e.g. like here). And most free software programs whose source code I have studied have such check, perhaps as some
Are there real life programs, e.g. packaged in a typical Linux distributions, which actually need and are using memory overcommitment in a sane and useful way? I know none of them!
What are the disadvantages of disabling memory overcommitment? Many older Unixes (e.g. SunOS4, SunOS5 from the previous century) did not have it, and IMHO their
malloc (and perhaps even the general full-system performance,
malloc-wise) was not much worse (and improvements since then are unrelated to memory overcommitment).
I believe that memory overcommitment is a misfeature for lazy programmers.