4 ms·
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 lat
by quotemstr 8mo ago
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 8mo agoIt'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 8mo agoOvercommit 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/797835/1027 https://unix.stackexchange.com/q/797841/1027 https://unix.stackexchange.com/q/797841/1027