On Wed 22-08-18 18:50:36, Luigi Semenzato wrote:

My apologies for not noticing this earlier, but we're often working
with older kernels.

On May 3, 2017 this patch was merged:

commit c822f6223d03c2c5b026a21da09c6b6d523258cd
Author:     Johannes Weiner [off-list ref]
AuthorDate: Wed May 3 14:52:10 2017 -0700
Commit:     Linus Torvalds [off-list ref]
CommitDate: Wed May 3 15:52:08 2017 -0700

    mm: delete NR_PAGES_SCANNED and pgdat_reclaimable()

I was planning to use this number as a measure of how much work the
kernel was doing trying to reclaim pages (by comparing it, for
instance, to the number of pages actually swapped in).  I am not even
sure how good a metric this would be.

I do not think it would be a good fit for that. NR_PAGES_SCANNED was
really volatile (any freed page would reset the counter).

Does anybody have suggestions for a good (or better) replacement?

I usually compare the number of pages scanned vs reclaimed from both
kswapd and allocator (direct reclaim) context. But it only tells you the
overall effectivity of the reclaim rather than how much _work_ had to be
done to release each page. Some of them would need to get unmapped
first. Some require to release buffers etc... I do not think we have a
good measure for that right now except for looking at tracepoints.

Johannes is working on pressure stall information [1] which might be
better fit for what you need.

[1] http://lkml.kernel.org/r/20180801151958.32590-1-hannes@cmpxchg.org
-- 
Michal Hocko
SUSE Labs