Re: [PATCH] mm: vmscan: consistent update to pgdeactivate and pgactivate

[Hao Lee <haolee.swjtu@gmail.com>]

On Fri, Aug 20, 2021 at 4:27 AM Shakeel Butt <shakeelb@google.com> wrote:
>
> On Thu, Aug 19, 2021 at 9:31 AM Hao Lee <haolee.swjtu@gmail.com> wrote:
> >
> > After the commit 912c05720f00 ("mm: vmscan: consistent update to
> > pgrefill"), pgrefill is consistent with pgscan and pgsteal. Only under
> > global reclaim, are they updated at system level. Apart from that,
> > pgdeactivate is often used together with pgrefill to measure the
> > deactivation efficiency and pgactivate is used together with
> > pgscan to measure the reclaim efficiency. It's also necessary to
> > make pgdeactivate and pgactivate consistent with this rule.
> >
> > Signed-off-by: Hao Lee <haolee@didiglobal.com>
>
> pgactivate and pgdeactivate are also updated in code paths other than
> memory reclaim like mark_page_accessed() or madvise(COLD). Wouldn't
> that impact your analysis of these metrics as well?

Thanks for pointing out this.
These paths indeed increase the pgdeactivate and pgactivate counter, but they
all can be seen as system-level. On the other hand, the deactivation and
activation in the cgroup try_charge() direct reclaim path is cgroup-level,
which is caused by artificial limits. If the system memory pressure is low, but
a cgroup is going through aggressive memory reclaim, then the two metrics will
increase continuously in both vmstat and memory.stat. I think this is not
reasonable. Suppose we exclude them from the cgroup direct reclaim path. In
that case, we can determine if the system level memory reclaim is hard to make
progress by using pgdeactivate/pgrefill and pgactivate/pgscan roughly
("roughly" means we temporarily ignore deactivation and activation in other
paths). One can still get these metrics in both system-level and cgroup-level
through memory.stat.

Regards,
Hao Lee