linux-kernel - Re: [PATCH] mm: vmscan: consistent update to pgsteal and pgscan

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200508133833.GA181181@cmpxchg.org>
Date:   Fri, 8 May 2020 09:38:33 -0400
From:   Johannes Weiner <hannes@...xchg.org>
To:     Shakeel Butt <shakeelb@...gle.com>
Cc:     Yafang Shao <laoar.shao@...il.com>, Mel Gorman <mgorman@...e.de>,
        Roman Gushchin <guro@...com>, Michal Hocko <mhocko@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linux MM <linux-mm@...ck.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mm: vmscan: consistent update to pgsteal and pgscan

On Fri, May 08, 2020 at 06:25:14AM -0700, Shakeel Butt wrote:
> On Fri, May 8, 2020 at 3:34 AM Yafang Shao <laoar.shao@...il.com> wrote:
> >
> > On Fri, May 8, 2020 at 4:49 AM Shakeel Butt <shakeelb@...gle.com> wrote:
> > >
> > > One way to measure the efficiency of memory reclaim is to look at the
> > > ratio (pgscan+pfrefill)/pgsteal. However at the moment these stats are
> > > not updated consistently at the system level and the ratio of these are
> > > not very meaningful. The pgsteal and pgscan are updated for only global
> > > reclaim while pgrefill gets updated for global as well as cgroup
> > > reclaim.
> > >
> >
> > Hi Shakeel,
> >
> > We always use pgscan and pgsteal for monitoring the system level
> > memory pressure, for example, by using sysstat(sar) or some other
> > monitor tools.

I'm in the same boat. It's useful to have activity that happens purely
due to machine capacity rather than localized activity that happens
due to the limits throughout the cgroup tree.

> Don't you need pgrefill in addition to pgscan and pgsteal to get the
> full picture of the reclaim activity?

I actually almost never look at pgrefill.

> > But with this change, these two counters include the memcg pressure as
> > well. It is not easy to know whether the pgscan and pgsteal are caused
> > by system level pressure or only some specific memcgs reaching their
> > memory limit.
> >
> > How about adding  cgroup_reclaim() to pgrefill as well ?
> >
> 
> I am looking for all the reclaim activity on the system. Adding
> !cgroup_reclaim to pgrefill will skip the cgroup reclaim activity.
> Maybe adding pgsteal_cgroup and pgscan_cgroup would be better.

How would you feel about adding memory.stat at the root cgroup level?

There are subtle differences between /proc/vmstat and memory.stat, and
cgroup-aware code that wants to watch the full hierarchy currently has
to know about these intricacies and translate semantics back and forth.

Generally having the fully recursive memory.stat at the root level
could help a broader range of usecases.