LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* [PATCH] mm: vmscan: consistent update to pgdeactivate and pgactivate
@ 2021-08-19 16:30 Hao Lee
  2021-08-19 20:26 ` Shakeel Butt
  0 siblings, 1 reply; 3+ messages in thread
From: Hao Lee @ 2021-08-19 16:30 UTC (permalink / raw)
  To: akpm; +Cc: hannes, shakeelb, linux-mm, linux-kernel, haolee.swjtu

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


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] mm: vmscan: consistent update to pgdeactivate and pgactivate
  2021-08-19 16:30 [PATCH] mm: vmscan: consistent update to pgdeactivate and pgactivate Hao Lee
@ 2021-08-19 20:26 ` Shakeel Butt
  2021-08-20  6:53   ` Hao Lee
  0 siblings, 1 reply; 3+ messages in thread
From: Shakeel Butt @ 2021-08-19 20:26 UTC (permalink / raw)
  To: Hao Lee; +Cc: Andrew Morton, Johannes Weiner, Linux MM, LKML

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?

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] mm: vmscan: consistent update to pgdeactivate and pgactivate
  2021-08-19 20:26 ` Shakeel Butt
@ 2021-08-20  6:53   ` Hao Lee
  0 siblings, 0 replies; 3+ messages in thread
From: Hao Lee @ 2021-08-20  6:53 UTC (permalink / raw)
  To: Shakeel Butt; +Cc: Andrew Morton, Johannes Weiner, Linux MM, LKML

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2021-08-20  6:53 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-19 16:30 [PATCH] mm: vmscan: consistent update to pgdeactivate and pgactivate Hao Lee
2021-08-19 20:26 ` Shakeel Butt
2021-08-20  6:53   ` Hao Lee

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).