3 ms·
The OOM killer can strike at any time, regardless of the mapping options you've set, even if you aren't explicitly or implicitly allocating new memory. What I'd
by dooglius 7y ago
The OOM killer can strike at any time, regardless of the mapping options you've set, even if you aren't explicitly or implicitly allocating new memory. What I'd like, and what I think twic is asking for, is a way to "opt-out" of the overcommit paradigm at a process level, so that allocations by a given process reserve memory and may fail, but in return the kernel promises not to OOM kill it.
- cheerlessbog 7y agoMost of my programming experience is in Windows. Can someone briefly explain why it doesn't seem to need an OOM killer? Is it happier to page? Or it always commits on allocation? Or something else.
- dooglius 7y agoWindows does not have fork(), which as a sibling comment indicates is one of the main issues with removing overcommit.
- detaro 7y agoAFAIK windows lets whatever application asks for memory and can't get it crash, whereas the OOM killer tries to be intelligent about what gets killed.
- cesarb 7y agoAFAIK, Windows always commits on allocation, growing the swap file if necessary.
- cheerlessbog 7y agoWhy doesn't Linux do this?
- bscphil 7y ago>so that allocations by a given process reserve memory and may fail, but in return the kernel promises not to OOM kill it The issue with this is that there are other processes on the system. If I start a program that used your idea for allocation, and it used 90% of my memory, a small growth in my memory usage might mean I run out. But because it's guaranteed not to OOM, another program gets killed rather than the one using 90% of the memory. If you want no OOM kills, you've got to disable overcommit globally.