1. Overcommit is a double‑edged sword – it can kill apps or keep them alive
“Memory overcommit means that once you run out of physical memory, the OOM killer will forcefully terminate your processes with no way to handle the error.” – renehsz
“It’s not harmful. It’s necessary for modern systems that are not “an ECU in a car.”” – PunchyHamster
2. Most production software is written to assume overcommit
“If you turn overcommit off then when you fork you double the memory usage.” – loeg
“Disabling overcommit is wasteful because of fork and because of the way thread stacks are allocated.” – EdiX
3. Fork/COW and memory accounting make disabling overcommit tricky
“The kernel has to count it as reserved because writes could require allocating memory and that’s not allowed to fail since it’s not a malloc.” – pm215
“In mode 2 the MAP_NORESERVE flag is ignored.” – laurencerowe
4. Tuning overcommit (ratio, swap, cgroups) is a pragmatic compromise
“The default vm.overcommit_ratio is 50 % which means that if no swap is available, on a system with 2 GB of total RAM, more than 1 GB of RAM can’t be allocated.” – vin10
“You can use cgroup resource controls to separately govern max memory and swap usage.” – MrDrMcCoy
These four threads capture the core debate: whether overcommit should be enabled, how it affects real‑world workloads, the technical nuances of fork/COW, and the practical knobs that let you balance safety, performance, and resource usage.