Calculate the memory threshold at which the Linux OOM killer is likely to trigger.
The kernel invokes the OOM killer as a last resort when it cannot satisfy a memory allocation even after reclaiming cache and exhausting swap — practically, this risk rises sharply once MemAvailable plus free swap approaches vm.min_free_kbytes, a reserve the kernel tries to keep free for atomic (non-blocking) allocations like network interrupt handling. When the OOM killer does trigger, it selects a victim process using a heuristic oom_score (roughly proportional to memory footprint, adjustable per-process via /proc/<pid>/oom_score_adj) — this calculator's oom_score_estimate is a simplified proxy for that ranking, not the kernel's exact computation.
OOM risk margin
margin = MemAvailable + SwapFree − min_free_kbytes
The kernel reserves a chunk of memory (governed by vm.min_free_kbytes) that regular allocations can't touch, to guarantee atomic/interrupt-context allocations always succeed. If regular memory pressure pushes available memory down to that reserve with no swap left to fall back on, OOM killer triggers even though the reserve itself is technically 'free'.
It computes an oom_score for every eligible process, heavily weighted by memory usage (RSS plus swap usage), adjusted by each process's oom_score_adj (settable to bias the kernel toward or away from killing a specific process, e.g. protecting a database with a negative adjustment) and some additional heuristics like process age and privilege level.
Yes — write a negative value to /proc/<pid>/oom_score_adj (down to -1000, which fully exempts it) to reduce its likelihood of being chosen. Use this carefully: it doesn't prevent OOM conditions, it just redirects the kernel's choice of victim to other processes.