Memory overcommit and exhaustion

A virtual reservation describes an address-space range. Commit accounting tracks certain potential private writable memory demands according to operating-system rules. Residency measures physical backing currently present. These values need not match, particularly for sparse mappings, shared file pages, and copy-on-write. Linux exposes CommitLimit and Committed_AS for system commit accounting, but their difference is not the number of free physical bytes. Counting only resident usage can miss promises that become physical demand together during a burst or a child's later writes.

Linux offers heuristic, permissive, and stricter overcommit policies. Their detailed accounting depends on mapping type; a writable private file mapping is different from a shared read-only file mapping because private modifications may need new anonymous backing. In stricter mode, the configured ratio or byte amount and swap contribute to the accounting limit. This mechanism is useful admission control, but it does not abolish cgroup limits, constrained allocations, stack growth, kernel overhead, hardware failures, or application bugs. Avoid turning a policy description into an unconditional guarantee that no process can ever be killed.

A container or service cgroup can reach its memory maximum while the host still has spare RAM. Reclaim and enforcement then operate within that resource boundary. In cgroup v2, memory.high is a pressure and throttling boundary, while memory.max is a harder limit with documented exceptions and enforcement behavior. Observe memory.events and the relevant ancestor limits rather than assuming an exit means the host ran out globally. Shared page charging and hierarchy also make it unsafe to derive a cgroup's current charge by simply adding a few process RSS readings.

An OOM decision selects victims under the applicable policy; it does not promise to kill the leaking process or the least valuable user request. Selection controls and protected tasks affect behavior, and userspace memory managers may also terminate workloads before the kernel's final exhaustion path. An abrupt kill may prevent the victim from running cleanup. Design checkpoints, idempotent retries, and durable ownership transitions so that losing one process does not corrupt the job record. A restart loop that reloads the same oversized state can recreate pressure faster than the system recovers.

Predict peak overlap rather than only final model size. An update may retain old and new weights simultaneously; a training step may create optimizer state and temporary workspaces after loading succeeds. Cap in-flight jobs by a measured per-job envelope, reject or defer excess work, and test allocation failure paths. Leaving headroom is meaningful only when tied to known uncertainties. A documented smaller batch that completes reliably is often more useful than accepting an arbitrarily large batch and hoping the OOM policy chooses a convenient victim.

The queue lab illustrates an upstream control through two separate runs. Press Reset, explicitly set both arrival four and service three, predict growth of one job per second from the initial four, then Play or Step. Reset again, set both arrival two and service three, predict drainage from four after four seconds, then Play or Step. Editing rates alone retains elapsed time; it does not preserve an existing backlog through a live intervention. If queued jobs retain buffers, bounded arrivals can reduce one source of retained memory. The model calculates no bytes, commit accounting, cgroup charges, or victim selection. Identify the real per-job measurements and rejection behavior needed for a service policy.