memory overcommit
Think of an airline that sells more tickets than there are seats, betting that some passengers will not show up. Most flights are fine, and the airline carries more people overall. But on the rare day when everyone shows up, there are not enough seats and someone gets bumped. Memory overcommit is the OS making the same bet: it promises processes more memory in total than physically exists, gambling that they will not all actually use their full promise at the same time.
Concretely, overcommit happens because processes routinely ask for (or are granted) far more address space than they ever touch — a program may reserve a huge buffer or, after a fork with copy-on-write, nominally own a full copy of the parent's memory it never writes. Since pages consume real frames only when actually used (thanks to demand paging and copy-on-write), the OS can safely hand out promises whose sum exceeds RAM plus swap, as long as the actually-used total stays within limits. The system tracks committed memory but defers backing it with real frames until each page is touched. This is why a process can succeed in allocating a block far larger than free RAM and only later, on use, discover whether the memory truly exists.
Why it matters: overcommit lets a machine run more and larger processes than a strict accounting would allow, improving utilization, and it makes copy-on-write fork practical. But it carries a real risk: if processes do cash in more of their promises than physical memory plus swap can cover, the OS has overpromised and must do something drastic. Some systems then kill a process to reclaim memory (on Linux, the out-of-memory killer); others refuse allocations conservatively up front. The honest tension is that overcommit improves efficiency in the common case but can cause surprising, hard-to-predict failures in the worst case — a deliberate trade of guaranteed safety for better average use, much like the overbooked flight.
Ten processes each allocate a 1 GB buffer on a machine with 6 GB of RAM, promising 10 GB total. Most never fill their buffer, so actual usage stays under 6 GB and all run fine. The danger is the day they all fill up at once — then the OS must page furiously or kill someone.
Promising more memory than exists works until everyone cashes in at once.
Overcommit relies on most promises never being fully used. When that assumption breaks and demand exceeds RAM plus swap, the result is not a clean error returned to the program — it can be an out-of-memory killer terminating a process, or severe thrashing, both hard to predict.