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 <hannes@xxxxxxxxxxx> > AuthorDate: Wed May 3 14:52:10 2017 -0700 > Commit: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> > 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@xxxxxxxxxxx -- Michal Hocko SUSE Labs
