mm, vmscan: enhance mm_vmscan_lru_shrink_inactive tracepoint
authorMichal Hocko <mhocko@suse.com>
Wed, 22 Feb 2017 23:44:30 +0000 (15:44 -0800)
committerLinus Torvalds <torvalds@linux-foundation.org>
Thu, 23 Feb 2017 00:41:29 +0000 (16:41 -0800)
commit5bccd16657e893e52e96547e7c2b5729d78d4e45
treee9ab0c655336dfd4ef72edbdf6f9add544e215e4
parent3c710c1ad11b4a856a396b181911568f3851a5d8
mm, vmscan: enhance mm_vmscan_lru_shrink_inactive tracepoint

mm_vmscan_lru_shrink_inactive will currently report the number of
scanned and reclaimed pages.  This doesn't give us an idea how the
reclaim went except for the overall effectiveness though.  Export and
show other counters which will tell us why we couldn't reclaim some
pages.

- nr_dirty, nr_writeback, nr_congested and nr_immediate tells
  us how many pages are blocked due to IO
- nr_activate tells us how many pages were moved to the active
  list
- nr_ref_keep reports how many pages are kept on the LRU due
  to references (mostly for the file pages which are about to
  go for another round through the inactive list)
- nr_unmap_fail - how many pages failed to unmap

All these are rather low level so they might change in future but the
tracepoint is already implementation specific so no tools should be
depending on its stability.

Link: http://lkml.kernel.org/r/20170104101942.4860-7-mhocko@kernel.org
Signed-off-by: Michal Hocko <mhocko@suse.com>
Acked-by: Hillf Danton <hillf.zj@alibaba-inc.com>
Acked-by: Mel Gorman <mgorman@suse.de>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
include/trace/events/vmscan.h
mm/vmscan.c