[quotemstr]

TBF, I think overcommit was and remains an ugliness in how we manage memory. I wish we'd solved the fork commit-charge-spike issue by encouraging vfork (and later, posix_spawn) more heavily, not by making the OS lie about the availability of memory.

The ship's long sailed though, so even I run with overcommit enabled and only grumble about what might have been.

[Skunkleton]

It's not just fork. The operating system overcommits memory all over the place. For example, when you map memory, that can/will succeed without actually mapping physical pages. Even "available" memory is put to some use and freed in an asynchronous way behind the scene, a process that is not always successful.

Honestly, I think overcommit is a good thing. If you want to give a process an isolated address space, then you have to allow that process to lay out memory as it sees fit, without having to worry too much about what else happens to be on the system. If you immediately "charge" the process for this, you will end up nit-picking every process on the system, even though with overcommit you would have been fine.

[man8alexd]

Overcommit allows much better memory utilization. People disable overcommit all the time and get surprised when their programs start failing mallocs while there are still tons of discardable page cache in the system.

https://unix.stackexchange.com/q/797835/1027

https://unix.stackexchange.com/q/797841/1027