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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 20 Aug 2021 14:53:05 +0800
From:   Hao Lee <haolee.swjtu@...il.com>
To:     Shakeel Butt <shakeelb@...gle.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Johannes Weiner <hannes@...xchg.org>,
        Linux MM <linux-mm@...ck.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mm: vmscan: consistent update to pgdeactivate and pgactivate

On Fri, Aug 20, 2021 at 4:27 AM Shakeel Butt <shakeelb@...gle.com> wrote:
>
> On Thu, Aug 19, 2021 at 9:31 AM Hao Lee <haolee.swjtu@...il.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@...iglobal.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