How Linux handles virtual memory overcommit
November 8, 2007
Following up yesterday's entry on the general background of system virtual memory limits, here's how
Linux deals with this issue. In its traditional way, Linux gives you
three options for what happens when a process tries to allocate some
more memory, controlled by the value of the
(Disclaimer: all of this assumes a relatively recent 2.6 kernel.)
The kernel's commit limit is your swap space plus some percentage of
real memory. You set the percentage with the
Whether or not it is enforcing it, the kernel always tracks the amount
of committed address space and reports it as
For both heuristic overcommit and strict overcommit, the kernel reserves a certain amount of memory for root. In heuristic mode, this is 1/32nd of free RAM; in strict overcommit mode it is 1/32nd of the percent of real memory that you set. This is hard-coded and not tunable, and I can't say I was entirely pleased to discover that our 64 GB compute server is reserving around 2 GB for root.
If you want the gory details, see the
Sidebar: How heuristic overcommit works
Heuristic overcommit attempts to work out how much memory the system could give you if it reclaimed all the memory it could and no other process used more RAM than it currently is; if you are asking for more than this, your allocation is refused. In specific, the theoretical 'free memory' number is calculated by adding up free swap space, free RAM (less 1/32nd if you are not root), and all space used by the unified buffer cache and kernel data that is labeled as reclaimable (less some reserved pages).
* * *
Atom feeds are available; see the bottom of most pages.