Understand OOM Killer: Read Linux oom_kill.c Source

When Memory Runs Out

The OOM killer chooses a process to terminate when the kernel cannot reclaim enough pages. It is a last resort after reclaim, swap, and compaction fail. Server operators know it from sudden Killed messages in logs.

How Linux Picks Victims

oom_kill.c scores tasks:

• oom_score_adj: user-tunable bias (-1000 to +1000)
• RSS and runtime: large, short-lived jobs often lose
• child tree: killing a parent may free a subtree

For example, a chrome renderer with high RSS and low oom_score_adj protection dies before sshd with negative adjustment.

Why This Matters in Production

Production teams running Postgres or Redis set /proc/PID/oom_score_adj to -1000 specifically to survive the badness-score algorithm in Linux's mm/oom_kill.c that you're reading here. Misjudging how CAP_SYS_ADMIN or oom_score_adj shifts that score is exactly why the wrong process , sometimes the database instead of the runaway script , gets SIGKILLed during real production incidents.

Debugging Checklist

Before you call the implementation done, walk failure modes on purpose. Test empty structures, single-element edge cases, maximum concurrency, and errno paths that must not crash the program. OS code usually fails in production when happy-path tests pass but invariants break under contention or memory pressure.

Implementation Notes

Keep structures small and name fields after kernel counterparts when possible. That lets you read man pages and kernel source side by side while you work. Print observable events during development; remove noisy logs once tests pass reliably.

For This Exercise

You will read mm/oom_kill.c (or a trimmed excerpt) and summarize the selection heuristic. This exercise requires correlating oom_score in /proc with which process your simulated pressure would target.