> >> The reclaim_folio_list uses a dummy reclaim_stat and is not being >> used. To know the memory stat, add a new trace event. This is useful how >> how many pages are not reclaimed or why. >> >> This is an example. >> mm_vmscan_reclaim_pages: nr_scanned=17 nr_reclaimed=17 nr_dirty=0 nr_writeback=0 nr_congested=0 nr_immediate=0 nr_activate_anon=0 nr_activate_file=0 nr_ref_keep=0 nr_unmap_fail=0 >> >> Currenlty reclaim_folio_list is only called by reclaim_pages, and >> reclaim_pages is used by damon and madvise. In the latest Android, >> reclaim_pages is also used by shmem to reclaim all pages in a >> address_space. >> > >This looks like it will add some overhead when tracing has been >enabled. Has this been measured and is it significant? Hi Thank you for your comment. Regarding the overhead, I think the new function reclaim_stat_add seems to make us feel overhead. I wanted to sum and print it once but I think I can remove the sum, and put the new trace_mm_vmscan_reclaim_pages into reclaim_folio_list to show stat for each node. > >Also, we're adding a significant amount of code for a simple trace >record. Do others think this is justifiable? The mm_vmscan_reclaim_pages I added is similar to the mm_vmscan_lru_shrink_inactive. If allowed, I think we can use DEFINE_EVENT for both trace events. Let me think more. Jaewon Kim
