compactsnoop(8)

✨ NAME ✨

compactsnoop(8) from the System Manager's Manual 💅

compactsnoop — Trace compact zone events. Uses Linux eBPF/bcc. 🦋

🌸 SYNOPSIS 🌸

compactsnoop [-h] [-T] [-p PID] [-d DURATION] [-K] [-e]

💖 DESCRIPTION 💖

okay so compactsnoop traces the compact zone events and shows you which processes are allocing pages with memory compaction 👀 this is lowkey so useful for figuring out when compact_stall (/proc/vmstat) keeps climbing, and whether some critical processes are the ones causing it 😭

it works by tracing the compact zone events using raw_tracepoints and one kretprobe ✨

💀 for the CentOS 7.6 (3.10.x kernel), check the version under tools/old, which uses an older memory compaction mechanism. different vibes, different code!

and since this uses BPF, only the root user can run this tool 🔐

🧚 REQUIREMENTS 🧚

you need CONFIG_BPF and bcc 🎀

✨ OPTIONS ✨

• -h — print the usage message 🙈
• -T — add a timestamp column 🕰️
• -p PID — only trace this process ID (filtered in-kernel) 🎯
• -d DURATION — how long the trace runs in total, in seconds ⏳
• -K — output a kernel stack trace 🧱
• -e — show the extended fields 🔍

🍓 EXAMPLES 🍓

trace all compact zone events:

# compactsnoop

trace all compact zone events, but only for 10 seconds:

# compactsnoop -d 10

🔥 FIELDS 🔥

• TIME(s) — when the call happened, in seconds ⏰
• COMM — the process name 🧑‍💻
• PID — the process ID 🪪
• NODE — the memory node 🧠
• ZONE — the zone of the node (like DMA, DMA32, NORMAL, etc) 🗺️
• ORDER — shows which order of allocation caused the memory compaction. -1 means all orders (for example, a write to /proc/sys/vm/compact_memory) 📦
• MODE — SYNC or ASYNC 🔄
• FRAGIDX (extra column) — short for fragmentation index, and it only makes sense if an allocation of the requested size would fail. if that's the case, the fragmentation index tells you whether external fragmentation or a lack of memory was the problem 🧩 you can use it to decide if page reclaim or compaction should be used 🤔

the index comes back between 0 and 1, to 3 decimal places:

• 0 => the allocation would fail due to lack of memory 🫠
• 1 => the allocation would fail due to fragmentation 🧃

• MIN (extra column) — the min watermark of the zone 💧
• LOW (extra column) — the low watermark of the zone 🌊
• HIGH (extra column) — the high watermark of the zone 🏊
• FREE (extra column) — the nr_free_pages of the zone 🆓
• LAT(ms) — the compact zone's latency, in milliseconds ⚡
• STATUS — the result of the compaction 📋

for the CentOS 7.6 kernel, the statuses are:

• "skipped" (COMPACT_SKIPPED): compaction didn't start, because it wasn't possible or direct reclaim was the better choice 🙅
• "continue" (COMPACT_CONTINUE): compaction should keep going to another pageblock ➡️
• "partial" (COMPACT_PARTIAL): direct compaction partially compacted a zone and there are suitable pages 🧩
• "complete" (COMPACT_COMPLETE): the full zone was compacted 🏁

for kernel 4.7 and above, the statuses are:

• "not_suitable_zone" (COMPACT_NOT_SUITABLE_ZONE): more detailed tracepoint output, internal to compaction 🔧
• "skipped" (COMPACT_SKIPPED): compaction didn't start, because it wasn't possible or direct reclaim was the better choice 🙅
• "deferred" (COMPACT_DEFERRED): compaction didn't start because it got deferred due to past failures 😵‍💫
• "no_suitable_page" (COMPACT_NOT_SUITABLE_PAGE): more detailed tracepoint output, internal to compaction 🔧
• "continue" (COMPACT_CONTINUE): compaction should keep going to another pageblock ➡️
• "complete" (COMPACT_COMPLETE): the full zone was scanned, but it wasn't successful at compacting suitable pages 😤
• "partial_skipped" (COMPACT_PARTIAL_SKIPPED): direct compaction scanned part of the zone but wasn't successful at compacting suitable pages 🥲
• "contended" (COMPACT_CONTENDED): compaction ended early due to lock contention 🔒
• "success" (COMPACT_SUCCESS): direct compaction ended after deciding the allocation should now succeed 🎉

🌈 OVERHEAD 🌈

this traces the kernel compact zone kprobe/kretprobe or raw_tracepoints and prints output for each event. the rate of events is generally expected to be low (< 1000/s), so the overhead is also expected to be negligible 🫶

🦋 SOURCE 🦋

this is from bcc 💜

https://github.com/iovisor/bcc

also check the bcc distribution for a companion _examples.txt file, which has example usage, output, and commentary for this tool 📚

💻 OS 💻

Linux 🐧

🚧 STABILITY 🚧

⚠️ Unstable — still in development, so don't be shocked if things shift 🙈

👑 AUTHOR 👑

Wenbo Zhang 🫡

---

okay bestie that's the whole tea ☕💖 this page is from the USER COMMANDS section, dated 2019-11-1, and it's all about compactsnoop(8) 🎀✨ stay iconic 💅🌸