← Interview Prep

Linux Kernel — Page Frame Reclaiming

Taking pages back under pressure: what's reclaimable (clean file first, dirty writeback, anon needs swap, slab shrinkers), the active/inactive LRU lists & second-chance/refault, watermarks with kswapd vs direct reclaim, swappiness & thrashing, and the OOM killer (incl. cgroup OOM).

When memory runs low, the kernel has to take pages back — deciding what to evict, writing out what's dirty, and doing it without stalling everyone. How reclaim works, and why "high memory use" is usually fine. Original, interview-focused notes; the pressure side of Memory Management.

Reclaim frees the easy pages first: clean file-cache pages can be dropped instantly (they're on disk already); dirty pages must be written back first; anonymous pages need swap. It runs in the background (kswapd) and, when that's not fast enough, synchronously in the allocating task (direct reclaim).

What's reclaimable

The LRU lists

• Each memory zone keeps active and inactive LRU lists, split into anon and file — so file cache and process memory age separately.
• It's a second-chance scheme, not strict LRU: pages start inactive; a reference promotes them to active; reclaim scans the inactive tail and evicts what wasn't touched. This approximates LRU cheaply.
• Refault detection / working-set: the kernel tracks pages evicted and quickly re-read, so it can tell a genuinely-hot working set from one-shot streaming and avoid thrashing the cache.

kswapd, direct reclaim & watermarks

• Zones have watermarks (min / low / high). Free drops below low → kswapd (per-node kernel thread) wakes and reclaims in the background up to high — async, no one waits.
• If an allocation still can't be satisfied → direct reclaim: the allocating task reclaims synchronously before its allocation returns — a real latency spike, and the reason a busy box "hitches."
• Below min, only atomic/emergency allocations are allowed.

Swap & swappiness

• vm.swappiness (0–100, 200 on newer kernels) biases the balance between reclaiming file cache vs swapping anonymous pages. Low = prefer dropping file cache; it does not disable swap.
• Swap isn't "slow RAM you should turn off" — it lets the kernel evict cold anonymous pages so hot pages and cache keep RAM. A little steady swap is healthy; heavy continuous swap-in/out is thrashing.

Last resort: the OOM killer

When reclaim can't free enough and there's no swap headroom, the OOM killer picks a victim by oom_score (roughly memory footprint, tunable with oom_score_adj) and kills it — logged in dmesg. Per-cgroup limits (memory.max) trigger a cgroup OOM scoped to that group, which is how containers get killed. See the troubleshooting angle.