[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20190226234950.GA19099@tower.DHCP.thefacebook.com>
Date: Tue, 26 Feb 2019 23:49:57 +0000
From: Roman Gushchin <guro@...com>
To: "up@...ck.org" <up@...ck.org>, "the@...ck.org" <the@...ck.org>,
"LRU@...ck.org" <LRU@...ck.org>,
"counts@...ck.org" <counts@...ck.org>,
"tracking@...ck.org" <tracking@...ck.org>
CC: Andrew Morton <akpm@...ux-foundation.org>,
Tejun Heo <tj@...nel.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"cgroups@...r.kernel.org" <cgroups@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Kernel Team <Kernel-team@...com>
Subject: Re: your mail
On Mon, Feb 25, 2019 at 03:16:29PM -0500, Johannes Weiner wrote:
> [resending, rebased on top of latest mmots]
>
> The memcg LRU stats usage is currently a bit messy. Memcg has private
> per-zone counters because reclaim needs zone granularity sometimes,
> but we also have plenty of users that need to awkwardly sum them up to
> node or memcg granularity. Meanwhile the canonical per-memcg vmstats
> do not track the LRU counts (NR_INACTIVE_ANON etc.) as you'd expect.
>
> This series enables LRU count tracking in the per-memcg vmstats array
> such that lruvec_page_state() and memcg_page_state() work on the enum
> node_stat_item items for the LRU counters. Then it converts all the
> callers that don't specifically need per-zone numbers over to that.
The updated version looks very good* to me!
Please, feel free to use:
Reviewed-by: Roman Gushchin <guro@...com>
Looking through the patchset, I have a feeling that we're sometimes
gathering too much data. Perhaps we don't need the whole set
of counters to be per-cpu on both memcg- and memcg-per-node levels.
Merging them can save quite a lot of space. Anyway, it's a separate
topic.
* except "to" and "subject" of the cover letter
Thanks!
Powered by blists - more mailing lists