Post #1546566
2026-04-14 22:02 UTC
@zwol @regehr while I sort of agree with parts of that, I wanted to point out that disabling memory overcommit *also* invokes a regulatory system without enough context: the allocator. Whether two programs can succeed now depends on their execution interleaving of their map requests, and the decision to fail must be made even earlier (at the time of mapping).
So while I agree it's often an improvement, it doesn't totally fix the issue I was describing.
Replies (1)
-
@zwol@masto.hackers.town 2026-04-15 01:38
@cliffle @regehr I do partially agree with that! However, the _effect_ of allocation failure is (in principle) easier to recover from when memory overcommit is disabled, and I think that tips the scale in favor of no overcommit, at least as a default. It _should_ also be paired with things like actually effective rlimits for memory usage, the ability to say "no _single process_ can occupy more than X% of physical RAM", etc.