4 ms·
It is a hen and egg situation. The OS has to do this because many applications have learned to rely on the behaviour and will pre-allocate huge amounts of memor
by tsss 2y ago
It is a hen and egg situation. The OS has to do this because many applications have learned to rely on the behaviour and will pre-allocate huge amounts of memory that they never use. Linux practically forces applications into this because the only way to start a new process is to fork yourself which will instantly double virtual memory usage for no reason. There's also the problem that a lack of overcommit tends to lead to underutilization. I'm eagerly waiting for the day that I no longer have to size my workloads manually on kubernetes.
- heavenlyblue 2y agoHow is forking related to overcommit?
- tsss 2y agoWhen you fork then a complete copy of the parent process is created, including all its memory. This memory is not actually copied until it is changed, but it still doubles the virtual memory usage. So without overcommit, even starting bash through a fork would immediately cause an OOM if your process uses more than 50% of physical memory.
- heavenlyblue 2y agoThat's an incorrect assumption though. Overcommit is for pages that have not been accessed yet, however when forking a valid use case is to share pre-loaded, mostly read-only memory between processes.
- matheusmoreira 2y ago> the only way to start a new process is to fork yoursel Not at all. Linux supports the clone system call which allows applications complete control over this. Linux user space chooses not to take advantage of it.