Commit 5647bc293ab1 ("mm: compaction: Move migration fail/success stats to migrate.c"), removed 3 items in /proc/vmstat. but the docs still has their explanation. let's remove them. "compact_blocks_moved", "compact_pages_moved", "compact_pagemigrate_failed",
Unified · Split
| @@ -401,21 +401,6 @@ compact_fail · 400 unmodified lines | ||
| 401 | 401 | is incremented if the system tries to compact memory |
| 402 | 402 | but failed. |
| 403 | 403 | |
| 404 | −compact_pages_moved | |
| 405 | − is incremented each time a page is moved. If | |
| 406 | − this value is increasing rapidly, it implies that the system | |
| 407 | − is copying a lot of data to satisfy the huge page allocation. | |
| 408 | − It is possible that the cost of copying exceeds any savings | |
| 409 | − from reduced TLB misses. | |
| 410 | − | |
| 411 | −compact_pagemigrate_failed | |
| 412 | − is incremented when the underlying mechanism | |
| 413 | − for moving a page failed. | |
| 414 | − | |
| 415 | −compact_blocks_moved | |
| 416 | − is incremented each time memory compaction examines | |
| 417 | − a huge page aligned range of pages. | |
| 418 | − | |
| 419 | 404 | It is possible to establish how long the stalls were using the function |
| 420 | 405 | tracer to record how long was spent in __alloc_pages_nodemask and |
| 421 | 406 | using the mm_page_alloc tracepoint to identify which allocations were |