Kernel · XB Field Notes

Linux overcommit is a policy the kernel bet on

Sat, 18 Dec 2027 00:00:00 +0000

Tuning vm.overcommit_memory shifts the failure point from a blind heuristic back to your own budget, which changes exactly who eats an OOM kill.

Why malloc rarely fails

vm.overcommit_memory defaults to 0, the heuristic mode that says yes to almost every mmap and malloc while it can plausibly honor them, and only refuses when the system is genuinely short on memory. Committing virtual memory costs almost nothing up front because pages are handed out lazily, so most allocations succeed and most normal applications stay alive at near-zero cost. The price of the generosity is that the kernel can over-commit far beyond RAM, betting that you will not touch every page; when many bytes actually get written, someone has to pay with an OOM kill.

The knob

vm.overcommit_memory lets you choose who holds the budget. The default 0 is heuristic overcommit: the kernel refuses only obviously impossible requests and otherwise says yes, trusting most processes never touch every byte they reserve. Setting it to 1 means always overcommit: almost any allocation is granted, which suits huge sparse mappings that stay mostly untouched, but every failure is pushed downstream to reclaim or the OOM killer. Setting it to 2 means strict accounting: any allocation beyond CommitLimit, roughly swap plus overcommit_ratio percent of RAM (overcommit_kbytes takes over when nonzero), fails with ENOMEM at request time. Neither extreme is free: always-overcommit hides pressure until the machine stalls, and strict mode breaks programs that reserve generously but touch little.

Heuristic versus strict

The real choice is who pays when the reckoning arrives. In heuristic mode the kernel keeps over-committing and, under pressure, picks a victim to kill; in strict mode the boundary is drawn in advance, so the failure surfaces at malloc time and the operator, not the scheduler, decides which process eats an OOM kill. Containers and VMs typically set a controlled value because a host over-committing on behalf of many guests can collapse when their aggregate demand spikes. A laptop can be generous; a production box that must not silently lose a worker should be explicit about its budget.

When it breaks

Under the default heuristic mode, the most confusing failure is a large malloc or mmap that returns success and then dies later. No pages were touched yet, so the allocation looked fine; once the process writes into them and memory runs short, the OOM killer picks a victim, often not the over-allocator but the largest nearby process. The log shows Out of memory: Killed process with no failed allocation in sight, so teams chase the wrong binary while the real over-reservation stays hidden.

Mode 1, always overcommit, fails slower. Absurd reservations are granted without protest, pressure builds silently, and a machine with swap slides into a swap storm where everything is alive but nothing progresses. Latency collapses before any kill frees memory, sessions stall, and the eventual OOM kill looks random because too many processes hold promises the system could never keep together.

Mode 2, strict accounting, fails at request time instead. A JVM reserving a large heap up front, or a fork-heavy service briefly needing twice its resident set accounted, gets ENOMEM at startup even though it would never touch every page. Operators who copy a strict overcommit_ratio from a swapless laptop onto a database host watch healthy programs refuse to start; size the ratio against the gap between CommitLimit and Committed_AS in /proc/meminfo instead of flipping the mode blindly.

Check it quickly

Save the following as overcommit_probe.py and run python3 overcommit_probe.py. It uses only the standard library, opens the overcommit_* knobs and /proc/meminfo read-only, changes nothing, and needs no privileges. Without those proc files it prints SKIP instead of failing.

"""Read-only overcommit audit: report mode, budget, and pressure."""

from pathlib import Path


def read_value(path):
 try:
 return Path(path).read_text(encoding="utf-8").strip()
 except FileNotFoundError:
 return None
 except OSError as exc:
 return "UNREADABLE: %s" % exc


def meminfo_kb(text):
 fields = {}
 for line in text.splitlines():
 name, _, rest = line.partition(":")
 digits = "".join(ch for ch in rest if ch.isdigit())
 if name and digits:
 fields[name.strip()] = int(digits)
 return fields


def main():
 mode = read_value("/proc/sys/vm/overcommit_memory")
 ratio = read_value("/proc/sys/vm/overcommit_ratio")
 kbytes = read_value("/proc/sys/vm/overcommit_kbytes")
 meminfo = read_value("/proc/meminfo")
 if mode is None or meminfo is None:
 print("SKIP: /proc/sys/vm/overcommit_memory or /proc/meminfo missing (non-Linux?)")
 return
 info = meminfo_kb(meminfo)
 print("overcommit_memory=%s overcommit_ratio=%s overcommit_kbytes=%s" % (mode, ratio, kbytes))
 print("MemTotal=%s kB SwapTotal=%s kB CommitLimit=%s kB Committed_AS=%s kB" % (
 info.get("MemTotal", "?"), info.get("SwapTotal", "?"),
 info.get("CommitLimit", "?"), info.get("Committed_AS", "?"),
 ))
 names = {"0": "heuristic", "1": "always overcommit", "2": "strict accounting"}
 print("mode means: %s" % names.get(mode, "unknown value"))
 limit = info.get("CommitLimit")
 committed = info.get("Committed_AS")
 if mode == "0":
 print("suggestion: heuristic default; watch Committed_AS growth, prefer mode 2 for workers that must not be OOM-killed")
 elif mode == "1":
 print("suggestion: always overcommit; expect swap storms under pressure, prefer 0 or 2 unless sparse mappings need it")
 elif mode == "2" and limit and committed:
 headroom = limit - committed
 print("commit headroom=%s kB; suggestion: enlarge ratio/kbytes if headroom is small, shrink them if headroom is huge" % headroom)
 else:
 print("suggestion: unexpected mode value; compare Committed_AS against CommitLimit before changing anything")


if __name__ == "__main__":
 main()

On a default workstation the script reports overcommit_memory=0 and names it heuristic. Under mode 2, compare the headroom: Committed_AS near CommitLimit explains startup ENOMEM, while huge headroom means the ratio is merely conservative. Under mode 1 the suggestion warns about swap storms, matching the slow-then-random failure above.

Sources

Kernel vm sysctl documentation, defines the overcommit_memory modes and defaults, checked 2026-06-01.
proc manual page, documents /proc/meminfo CommitLimit and Committed_AS accounting, checked 2026-06-01.

sysctl tunes the running kernel

Sun, 22 Nov 2026 00:00:00 +0000

sysctl is not a configuration file format. It is a live view of the kernel’s parameter table, reachable by dotted name and mirrored under /proc/sys, so reading and writing a value is literally reading and writing a pseudo-file. That is why sysctl -w takes effect immediately and why nothing set that way survives a reboot.

The tension is all in the second half: persistence. The runtime interface is honest and immediate, while the file meant to make a setting stick is subject to filename precedence, an implementation split over /etc/sysctl.conf, and a failure mode where a line quietly does nothing.

A key is a path into a live table

Every dotted key maps to one pseudo-file, net.ipv4.ip_forward to /proc/sys/net/ipv4/ip_forward, and sysctl(8) notes that procfs is required. sysctl -a enumerates the table, skipping deprecated and verboten parameters, and one exclusion is a warning in itself: stat_refresh returns no value but flushes per-CPU VM statistics, so reading everything is not always free.

Because it is a live table rather than stored configuration, the key set is stable and the values are not: on the macOS host used for the fixture, sysctl -a returned 1917 keys across 14 namespaces, and two consecutive reads produced an identical key set while 47 lines changed value. Reads and writes share one handler: an unknown key gives ENOENT, a read-only key refuses the write, and an unparseable value gives EINVAL. No daemon holds state.

Runtime first, persistence second

sysctl -w key=value applies to the running kernel and writes nothing anywhere, which makes it the right tool for testing. Persisting means a file the init system reads, and there the two implementations disagree: procps sysctl --system reads /etc/sysctl.d, /run/sysctl.d, /usr/local/lib/sysctl.d, /usr/lib/sysctl.d and /lib/sysctl.d, then /etc/sysctl.conf last, while systemd-sysctl reads the drop-in directories and, as sysctl.conf(5) states, does not use /etc/sysctl.conf at all.

Precedence is by filename, not directory: all configuration files are sorted lexicographically regardless of where they live, a same-named file in an earlier directory masks the later one, and for a given key the lexicographically latest filename wins. Hence the convention of a two-digit prefix and a dash, 10-40 for vendor files and 60-90 for local ones, so the local file sorts last regardless of which directory the reader walked first.

The failure is a line that quietly did nothing

sysctl.d(5) splits errors into two classes, and the split is the whole story. A permission error, or an attempt to write a variable that is not present on the local system, is logged at debug level and does not fail the service; other errors are louder and do cause a failure. So a line for a module-gated key, such as net.bridge.bridge-nf-call-iptables before br_netfilter is loaded, is dropped quietly and sysctl --system still exits zero. The page’s remedy is to load the module first, via a udev rule or modules-load.d.

The second quiet failure is ordering. The value in effect is whatever the last writer set, so a container runtime or a unit’s own ExecStartPre writing the same key after your drop-in wins without touching your file, and a reload that reports success is not evidence that your value is the one in effect. The - prefix, or -e, suppresses even the loud errors, so a typo becomes invisible too.

When it breaks

The classic failure is a config that reads correctly and does nothing. The file is on disk, sysctl --system exits zero, and the key still holds its default, because it did not exist when the loader ran or because something wrote it afterwards. Diagnose by reading the key back rather than re-reading the file: sysctl <key> shows the effective value, and comparing it against what the file claims is the whole test.

The second failure is a container that believes it tuned the host. net.* is per network namespace, so two containers can hold different values, but vm.* and most kernel.* keys are global; from a container they either change the whole machine or fail with EROFS when /proc/sys is read-only. A sysctl -w in an entrypoint is therefore not portable, and one that silently does nothing is worse than one that fails.

Check it quickly

sysctl -a | wc -l
sysctl net.ipv4.ip_forward net.core.somaxconn
sysctl -n net.ipv4.ip_forward
sysctl --system; echo "exit=$?"
grep -r . /etc/sysctl.d/ 2>/dev/null | head

The first line proves the table is enumerable, and the next two show the difference that matters when scripting: plain sysctl prints key: value, while -n prints the bare value. sysctl --system should exit zero, but that exit code proves very little, because a missing key is debug-level and non-fatal, so follow it with sysctl <key> for every key you claim to manage. The grep shows which files exist; remember that a same-named file in /run or /usr/lib may be masked, and that /etc/sysctl.conf is read by procps sysctl but not systemd-sysctl.

Sources

sysctl(8), the runtime interface, the –system file order, and the deprecated and verboten parameters, checked 2026-09-16.
sysctl.conf(5), the line format, the “-” prefix, and the note that systemd-sysctl does not read /etc/sysctl.conf, checked 2026-09-16.
sysctl.d(5), drop-in precedence and the error classes that decide whether a failed line is even reported, checked 2026-09-16.

Kernel · XB Field Notes

Linux overcommit is a policy the kernel bet on

Why malloc rarely fails

The knob

Heuristic versus strict

When it breaks

Check it quickly

Further reading

Sources

sysctl tunes the running kernel

A key is a path into a live table

Runtime first, persistence second

The failure is a line that quietly did nothing

When it breaks

Check it quickly

Sources