memory overcommitment

[D. Hugh Redelmeier]

When Jim Mercer spoke at our meeting earlier this month, one Linux feature 
that had him shaking his head was memory overcommitment.

Normally, Linux will effectively promise processes more memory than it can 
deliver.  This is called overcommitment.

Why would this be a good idea?  Because many processes don't use the worst 
case of what they can, and usually not all running processes are 
simultaneously using their maximal amount.

Why would this be a bad idea?  Because failure (i.e. running out of memory 
and swap space to support the requirements) is hard to recover from and it 
is not connected in any obvious way with the requests that caused the 
problem.  The way Linux recovers is the "OOM killer" -- a process that 
kills dead somewhat random processes in the hope that memory requirements 
become become small enough to handle.

The OOM Handler behaviour makes it extremely hard to reason about how a 
system will perform.

You can tell Linux not to overcommit.  That sounds easy and reasonable.  I 
didn't know why you would not want to do this.

Here's an interesting article that addresses the issue: 
<http://www.quora.com/What-are-the-disadvantages-of-disabling-memory-overcommit-in-Linux>

If I read this right, it seems as if Linux has a cute generalization that 
makes it expensive to avoid overcommitment.

Copy On Write (COW) is really neat.  Two processes created by forking can 
share all their memory until one writes to it.  Then the page that is 
written two must be copied so that each process has its own copy.

With COW, a fork causes almost no memory use but writes afterwards do.  To 
properly account for this without overcommitment, the system would have to 
account for complete copying on fork, even though that is probably way too 
generous.

But: in a properly designed system, much of the memory of a process should 
be read-only and never have to be copied: the program code itself and any 
constants.  Reading between the lines, it sounds as if Linux doesn't 
enforce this.

I wonder if it is true.

Even if this were fixed, fork needs to account for duplication of all the 
heap and stack.  If, as is often the case, the next serious thing that the 
child process does is exec, the allocation of the space for the child's 
heap and stack is a wicked waste.  Another argument for the abomination 
vfork which recognized this idiom.

Reading in between the lines in these documents, I'm guessing that glibc's 
malloc implementation assumes that allocating memory that isn't used 
doesn't have a cost.  This is not true if overcommit is forbidden.

Still a bit of a puzzle to me.
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists