RE: [PATCH] vmscan: add a vmscan event for reclaim_pages

[Jaewon Kim <jaewon31.kim@samsung.com>]

>
>> 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