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

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

[Hao Lee]

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>
---
 mm/vmscan.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 403a175a720f..9242c01d03ac 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1814,7 +1814,8 @@ static unsigned int shrink_page_list(struct list_head *page_list,
 	free_unref_page_list(&free_pages);
 
 	list_splice(&ret_pages, page_list);
-	count_vm_events(PGACTIVATE, pgactivate);
+	if (!cgroup_reclaim(sc))
+		count_vm_events(PGACTIVATE, pgactivate);
 
 	return nr_reclaimed;
 }
@@ -2427,7 +2428,8 @@ static void shrink_active_list(unsigned long nr_to_scan,
 	/* Keep all free pages in l_active list */
 	list_splice(&l_inactive, &l_active);
 
-	__count_vm_events(PGDEACTIVATE, nr_deactivate);
+	if (!cgroup_reclaim(sc))
+		__count_vm_events(PGDEACTIVATE, nr_deactivate);
 	__count_memcg_events(lruvec_memcg(lruvec), PGDEACTIVATE, nr_deactivate);
 
 	__mod_node_page_state(pgdat, NR_ISOLATED_ANON + file, -nr_taken);
-- 
2.31.1

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

[Shakeel Butt]

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?

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

[Hao Lee]

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