In this lesson, you will learn how to identify and quantify the performance penalties imposed by kernel page migration during memory compaction cycles.
The Mechanics of Migration
When the Linux kernel detects memory fragmentation—where large contiguous blocks of physical memory are unavailable—it initiates memory compaction. This process moves active pages from one memory region to another to consolidate free space. While necessary for satisfying high-order allocation requests, this movement is expensive: it consumes CPU cycles, involves locking memory management (MM) structures, and stalls processes waiting for page stability.
When a workload is latency-sensitive, the "stop-the-world" effect of migration can manifest as erratic latency spikes that are often mistaken for scheduling delays or I/O bottlenecks.
Identifying the Bottleneck
To observe the impact of migration, we focus on the compact_migrate_pages tracepoint. By measuring the duration of these migration operations, we can correlate memory pressure with execution stalls. Use trace-cmd or bpftrace to capture the latency of these events:
# Capture the latency of page migration in microseconds
bpftrace -e 'tracepoint:compaction:mm_compaction_migratepages { @start[tid] = nsecs; }
tracepoint:compaction:mm_compaction_end /@start[tid]/ {
@lat = hist(nsecs - @start[tid]); delete(@start[tid]); }'
Analyzing the Impact
If your histogram shows a long tail of high-latency events, the kernel is likely spending significant time relocating pages while your application waits for those pages to become accessible.
A critical symptom to watch for is the relationship between compaction and Context Switch Overhead. Since page migration involves holding locks on the page tables (PTEs) and the zone->lru_lock, it can cause threads to block while attempting to resolve page faults. If you notice that your high-latency spikes correlate with increased mm_compaction_migratepages activity, the system is struggling to balance the demand for contiguous memory against the cost of reorganizing existing resident sets.
When troubleshooting, check /proc/vmstat for compact_migrate_scanned and compact_free_scanned. High numbers here indicate that the kernel is aggressively hunting for pages to move, confirming that the cost you are seeing is the result of an ongoing struggle to alleviate chronic memory fragmentation.
Key Takeaway: Page migration bottlenecks occur when the kernel’s background effort to defragment memory inadvertently steals CPU cycles and introduces locking contention, forcing latency-sensitive tasks to wait for memory management operations to complete.