Linux memory overcommit: overcommit_memory 0, 1, 2 and reading CommitLimit

On Linux, a successful memory allocation does not by default guarantee that the memory will be there when you actually use it later. How strictly the kernel checks allocation requests is set by vm.overcommit_memory. This post covers the three modes and how to read CommitLimit and Committed_AS in /proc/meminfo, following three kernel documents: Overcommit Accounting, the /proc/sys/vm documentation and the /proc filesystem documentation.

The three modes

You can check the current value with:

cat /proc/sys/vm/overcommit_memory

Value	Name in the docs	Behavior
`0` (default)	Heuristic overcommit	Compares the request size against total memory plus swap and refuses only obvious overcommits. A seriously wild allocation fails; other overcommit is allowed, which reduces swap usage.
`1`	Always overcommit	Acts as if there is always enough memory until it actually runs out.
`2`	Don’t overcommit	The total commit for the system may not exceed swap plus a configurable share of physical RAM (50% by default).

The documentation gives some scientific code as a fit for mode 1: code that uses sparse arrays and relies on virtual memory consisting almost entirely of zero pages. Mode 2 is described as useful for applications that want a guarantee that their allocations will be available later without having to initialize every page. As for why overcommit is useful at all, the /proc/sys/vm documentation points out that many programs malloc() huge amounts of memory “just in case” and don’t use much of it.

Details such as what mode 0 treats as an “obvious” overcommit are not in the documentation. The /proc/sys/vm documentation points to __vm_enough_memory() in the kernel source file mm/util.c for more information; this post does not go into that source.

CommitLimit: the ceiling enforced in mode 2

CommitLimit in /proc/meminfo is the current commit limit, and Committed_AS is the amount committed so far. The /proc documentation gives this formula for CommitLimit:

CommitLimit = ([total RAM pages] − [total huge TLB pages]) × overcommit_ratio / 100 + [total swap pages]

The documentation’s example: with 1G of physical RAM, 7G of swap and a vm.overcommit_ratio of 30, CommitLimit is 7.3G. That is 30% of 1G, or 0.3G, plus 7G of swap.

To set an absolute amount instead of a percentage, use vm.overcommit_kbytes. The committed total may then not exceed swap plus that amount of physical RAM. You can’t use both: setting one disables the other, which then reads as 0.

One point is easy to miss. CommitLimit always shows up in /proc/meminfo, but only mode 2 actually enforces it. overcommit_ratio and overcommit_kbytes also only take effect in mode 2. So on a system in mode 0 or 1, a Committed_AS larger than CommitLimit does not by itself mean something is misconfigured. That last sentence is this post’s reading of the documentation’s statement that the limit is only adhered to in mode 2.

Committed_AS is what was promised, not what is used

Committed_AS is the sum of memory allocated by processes, including parts they haven’t used yet. In the /proc documentation’s example, a process that malloc()s 1G and touches only 300M of it counts as 1G. That 1G has been “committed” by the VM, that is, promised, and the allocating application can use it at any time.

What each kind of mapping costs follows the rules in the Overcommit Accounting document:

Mapping	Cost counted
File-backed, SHARED or read-only	0 (the file backs the mapping, not swap)
File-backed, PRIVATE and writable	Size of the mapping, per instance
Anonymous or `/dev/zero`, SHARED	Size of the mapping
Anonymous or `/dev/zero`, PRIVATE and read-only	0 (but of little use)
Anonymous or `/dev/zero`, PRIVATE and writable	Size of the mapping, per instance

In addition, pages made into writable copies by mmap and shmfs memory are drawn from the same pool. The document’s status list says that mmap mappings, mprotect changes, mremap size changes, brk and munmap are accounted, while accounting for ptrace pages is still on the to-do list.

Checking the values on your system

grep -E '^(MemTotal|SwapTotal|CommitLimit|Committed_AS|HugePages_Total):' /proc/meminfo
cat /proc/sys/vm/overcommit_ratio /proc/sys/vm/overcommit_kbytes

Let’s check the sample output printed in the /proc documentation this way. It contains these values:

MemTotal:       32858820 kB
SwapTotal:             0 kB
CommitLimit:    16429408 kB
Committed_AS:    7715148 kB
HugePages_Total:       0

The sample doesn’t show overcommit_ratio, so assume the default of 50. With no swap, half of MemTotal is 16,429,410 kB, while the actual CommitLimit is 16,429,408 kB, 2 kB less. The formula is defined in pages and the documentation doesn’t explain the gap, so a calculation from MemTotal is safest used only as an approximate check. In the same sample, Committed_AS (about 7.7 GB) is below CommitLimit (about 16.4 GB).

HugePages_Total is in the list because the formula subtracts huge TLB pages. If it isn’t 0, take that into account. The exact meaning of the hugetlb fields is outside the documents this post relied on.

Where things fail

In mode 2, the documentation says that in most situations a process will not be killed while accessing pages but will get errors on memory allocation instead. Note the “in most situations”. The documentation’s Gotchas section lists two points:

Stack growth in C does an implicit mremap. If you want absolute guarantees and run close to the edge, you must mmap your stack for the largest size you think you will need. For typical stack usage this doesn’t matter much.
In mode 2, the MAP_NORESERVE flag is ignored.

Mode 1 defers failure until memory actually runs out. Mode 0 may refuse a request earlier, at allocation time, when its heuristic judges it an obvious overcommit. If an OOM does occur, these two /proc/sys/vm settings affect whether the kernel panics and how the task to kill is chosen:

panic_on_oom: at the default of 0, the kernel picks a rogue process and kills it (the OOM killer). Setting 1 or 2 makes the kernel panic instead. With 1, if a process limited to certain nodes by mempolicy or cpusets exhausts those nodes, the OOM killer may kill a process and no panic occurs; with 2, the whole system panics even for an OOM inside a memory cgroup.
oom_kill_allocating_task: at the default of 0, the OOM killer scans the entire task list and picks a task to kill by heuristics. If non-zero, it simply kills the task that triggered the out-of-memory condition and avoids the tasklist scan. If panic_on_oom is set, it takes precedence.

Before switching to mode 2

First, work out what the limit will be. As a made-up example, on a server with 16GiB of RAM, no swap, no huge TLB pages and the default overcommit_ratio of 50, CommitLimit is about 8GiB. In mode 2, allocations that would push the committed total past that are refused, regardless of actual usage. With a ratio of 50 and no huge TLB pages, it also follows directly from the formula that the limit ends up below the size of RAM whenever swap is smaller than half of RAM.

Then look at the two reserves:

user_reserve_kbytes: in mode 2, keeps free memory of min(3% of the current process size, this value) in reserve. It is meant to stop a user from starting a single memory-hogging process and then being unable to kill it. The default is min(3% of the current process size, 128MB), and it has no effect in modes 0 and 1. If you reduce it to zero, a single process may allocate all free memory minus admin_reserve_kbytes, and any later attempt to run a command fails with “fork: Cannot allocate memory”.
admin_reserve_kbytes: free memory reserved for users with the cap_sys_admin capability. The default is min(3% of free pages, 8MB), intended to be enough for an admin to log in and kill a process under the default heuristic mode. The documentation warns that systems in mode 2 should raise it to cover the full virtual memory size of the programs used for recovery; otherwise root may not be able to log in. Its estimates for x86_64, counting sshd or login, a shell and tools such as top, are about 8MB in heuristic mode and about 128MB in mode 2.

Changes to either value take effect whenever an application requests memory. The /proc documentation advises against changing kernel parameters directly on a production system and recommends testing on a development machine first.

Who gets killed: oom_score_adj

You can influence which process the OOM killer picks with the per-process /proc/<pid>/oom_score_adj. Accepted values range from -1000 to +1000, and the value is added to the badness score before the target is chosen. -1000 is equivalent to disabling OOM killing for that task. /proc/<pid>/oom_score shows the current score; because it includes oom_score_adj, it is effectively in the range 0 to 2000. Lowering the value below the last one set by a CAP_SYS_RESOURCE process requires CAP_SYS_RESOURCE.

Scope and limits of this post

This post is based on the docs.kernel.org documentation (7.3.0-rc6 build) checked on 2026-10-12. The header of the /proc/sys/vm document still carries an old line saying it is valid for Linux 2.6.29; this post follows the current content published in the same build. Older kernels may have different entries or defaults.
The defaults quoted from the documentation are kernel defaults. Check the actual values on your system with the commands above.
This post does not cover mode 0’s detailed decision logic (__vm_enough_memory()) or OOM caused by hitting a cgroup memory limit. On the latter, the /proc documentation only says that when OOM is due to a memory limit, the “allowed memory” used for the badness calculation is that configured limit.
The kernel documentation does not recommend a mode for general servers. It describes what each mode is for, and this post doesn’t recommend one either.

CommitLimit is a ceiling on the total that can be promised, while MemAvailable is an estimate of how much memory new programs can get without swapping. They answer different questions. Reading MemAvailable is covered in the post on free’s available column.