If you are following our free Linux kernel development course or our free Linux device drivers course, this lecture on Linux memory overcommit is a must-read before you move on to process memory management and the OOM killer. Memory overcommit is one of those kernel behaviors that quietly runs on every Linux machine you use, yet very few engineers ever look under the hood.

In this article, we explain what memory overcommit really is, how the three overcommit modes work, how the kernel calculates the commit limit, and how you should tune it on a real production or embedded Linux system running a current 6.x kernel.

To get the most out of this lecture you should already be comfortable with:

• Basic C programming and the idea of a process address space
• What malloc() does at a conceptual level
• Basic Linux command-line usage and root/sudo access on a test VM

Memory overcommit is the kernel policy that allows a system to hand out promises of memory that exceed the amount of RAM and swap actually installed. When an application calls malloc(), mmap(), or brk(), the kernel does not immediately hand over physical RAM. Instead, it reserves a range of virtual addresses and defers the real work until the memory is actually touched.

Because most programs allocate far more virtual memory than they ever fully touch, the kernel can safely “overbook” memory the same way an airline overbooks seats, betting that not everyone will show up at once. This is the entire reason overcommit exists: it lets large, sparse allocations succeed without wasting real RAM up front.

The overcommit behavior is controlled by a single kernel tunable, vm.overcommit_memory, exposed through /proc/sys/vm/overcommit_memory. It accepts three values, and this has not changed across kernel releases from the 5.x series through the current 6.x LTS kernels.

You can check the current mode on any modern distribution with:

$ sysctl vm.overcommit_memory
vm.overcommit_memory = 0

When vm.overcommit_memory is set to 2, the kernel calculates a hard ceiling called the commit limit. This is where two closely related tunables come in: overcommit_ratio and the newer overcommit_kbytes.

CommitLimit = (Total RAM - Reserved Kernel Pages) * (overcommit_ratio / 100) + Swap

Instead of a percentage, you can set an absolute value directly using overcommit_kbytes, which is handy on servers with very large amounts of RAM where a percentage-based ratio becomes hard to reason about:

# Set overcommit_ratio to 80 percent
$ sudo sysctl -w vm.overcommit_ratio=80

# OR set an absolute kilobyte limit instead (mutually exclusive with overcommit_ratio)
$ sudo sysctl -w vm.overcommit_kbytes=8000000

You can always see the calculated limit the kernel is currently enforcing:

$ grep CommitLimit /proc/meminfo
CommitLimit:    12345678 kB

On current distributions (Ubuntu 24.04, Fedora 40+, Debian 12+, all running 6.x kernels) the mechanism is identical to older kernels described in classic kernel textbooks, but the recommended tooling has shifted toward sysctl and persistent configuration files rather than editing /proc by hand.

# Make the setting persistent across reboots
$ echo "vm.overcommit_memory = 2" | sudo tee /etc/sysctl.d/99-overcommit.conf
$ echo "vm.overcommit_ratio = 80" | sudo tee -a /etc/sysctl.d/99-overcommit.conf
$ sudo sysctl --system

A detail that classic kernel books rarely cover is how overcommit interacts with containers. vm.overcommit_memory is a global, host-wide sysctl, not a per-namespace setting. A container running under Docker, Podman or Kubernetes shares the host’s overcommit policy. What actually protects one container from starving another is the separate memory.max (cgroup v2) or memory.limit_in_bytes (cgroup v1) control, which is enforced independently of overcommit accounting. Understanding this separation is essential for anyone tuning free embedded systems or free Linux device drivers workloads that run inside containers today.

• In-memory databases (Redis, Memcached): rely on heuristic overcommit so that fork()-based background saves succeed without doubling resident memory.
• JVM-based services: the JVM reserves a large virtual heap up front; overcommit lets this succeed even though the heap is never fully touched.
• Embedded and IoT boards: engineers often switch to mode 2 on memory-constrained boards to fail fast and predictably instead of triggering the OOM killer later.
• HPC and scientific computing: sparse matrix allocations depend heavily on mode 1 (always overcommit).

• Leave vm.overcommit_memory at the default (0) unless you have a specific, measured reason to change it.
• On memory-critical embedded targets, prefer overcommit_kbytes over a percentage for predictable, absolute limits.
• Always pair overcommit tuning with cgroup memory limits in containerized environments.
• Monitor CommitLimit alongside actual usage using /proc/meminfo in your observability stack.

Heuristic and always-overcommit modes generally give better performance for typical workloads because processes rarely block on allocation checks. Strict mode (2) adds a small amount of allocation-time overhead but buys predictability, which matters more on latency-sensitive embedded and real-time systems than raw throughput.

Overcommit itself is not a direct attack surface, but unconstrained overcommit combined with no cgroup limits can allow a single misbehaving or malicious process to exhaust system memory and trigger unpredictable OOM kills of unrelated processes. Combining sane overcommit settings with per-service cgroup memory limits is the recommended hardening approach on any multi-tenant Linux system.

• Memory overcommit lets Linux hand out more virtual memory than physical RAM and swap combined.
• vm.overcommit_memory has three modes: heuristic (0), always (1), and strict (2).
• In strict mode, the commit limit is calculated from RAM, swap and overcommit_ratio or overcommit_kbytes.
• Containers rely on separate cgroup memory limits, not overcommit, for isolation.
• The default heuristic mode is correct for the vast majority of workloads.

Memory overcommit is a foundational piece of how Linux manages memory efficiently, and understanding it is essential groundwork before studying the OOM killer, which we cover in the next lecture of this free Linux kernel development course. Once you are comfortable with overcommit modes, commit limits, and how containers change the picture, you are ready to look at what happens when the kernel actually runs out of memory to give.