On Thu, 8 Dec 2016, Vlastimil Babka wrote: > > A "compact_daemon_wake" vmstat exists that represents the number of times > > kcompactd has woken up. This doesn't represent how much work it actually > > did, though. > > > > It's useful to understand how much compaction work is being done by > > kcompactd versus other methods such as direct compaction and explicitly > > triggered per-node (or system) compaction. > > > > This adds two new vmstats: "compact_daemon_migrate_scanned" and > > "compact_daemon_free_scanned" to represent the number of pages kcompactd > > has scanned as part of its migration scanner and freeing scanner, > > respectively. > > > > These values are still accounted for in the general > > "compact_migrate_scanned" and "compact_free_scanned" for compatibility. > > > > It could be argued that explicitly triggered compaction could also be > > tracked separately, and that could be added if others find it useful. > > > > Signed-off-by: David Rientjes <rientjes@xxxxxxxxxx> > > A bit of downside is that stats are only updated when compaction finishes, but > I guess it's acceptable. Also I don't think the compact_control variables need > the "total_" prefix, but no strong feelings. The explicit zero init should be > also unnecessary. > I actually prefer to have stats updated when compaction is finished for a single cycle, otherwise you get partially updated results: you have to make an inference of when a single compact_stall begins and ends. If you need detailed data for a single invocation of compaction, tracepoints would be much better. > Acked-by: Vlastimil Babka <vbabka@xxxxxxx> Thanks! -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>