From: Roman Gushchin <guro@fb.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
Michal Hocko <mhocko@kernel.org>,
Johannes Weiner <hannes@cmpxchg.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Kernel Team <Kernel-team@fb.com>,
Vladimir Davydov <vdavydov.dev@gmail.com>
Subject: Re: [PATCH v2 2/3] mm: memcontrol: flush percpu slab vmstats on kmem offlining
Date: Mon, 19 Aug 2019 22:46:50 +0000 [thread overview]
Message-ID: <20190819224645.GA9473@tower.dhcp.thefacebook.com> (raw)
In-Reply-To: <20190819152744.4ab8478cfb8697856408425b@linux-foundation.org>
On Mon, Aug 19, 2019 at 03:27:44PM -0700, Andrew Morton wrote:
> On Mon, 19 Aug 2019 13:23:37 -0700 Roman Gushchin <guro@fb.com> wrote:
>
> > I've noticed that the "slab" value in memory.stat is sometimes 0,
> > even if some children memory cgroups have a non-zero "slab" value.
> > The following investigation showed that this is the result
> > of the kmem_cache reparenting in combination with the per-cpu
> > batching of slab vmstats.
> >
> > At the offlining some vmstat value may leave in the percpu cache,
> > not being propagated upwards by the cgroup hierarchy. It means
> > that stats on ancestor levels are lower than actual. Later when
> > slab pages are released, the precise number of pages is substracted
> > on the parent level, making the value negative. We don't show negative
> > values, 0 is printed instead.
> >
> > To fix this issue, let's flush percpu slab memcg and lruvec stats
> > on memcg offlining. This guarantees that numbers on all ancestor
> > levels are accurate and match the actual number of outstanding
> > slab pages.
> >
> > Fixes: fb2f2b0adb98 ("mm: memcg/slab: reparent memcg kmem_caches on cgroup removal")
> > Signed-off-by: Roman Gushchin <guro@fb.com>
> > Cc: Johannes Weiner <hannes@cmpxchg.org>
> > Cc: Michal Hocko <mhocko@kernel.org>
> > Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
>
> [1/3] and [3/3] have cc:stable. [2/3] does not. However [3/3] does
> not correctly apply without [2/3] having being applied.
Right, [2/3] is required by slab kmem reparenting, which appeared in 5.3.
I can rearrange [2/3] and [3/3] so that first two patches will have
cc table and apply correctly. Let me do this, I'll send v3 shortly.
Thanks!
next prev parent reply other threads:[~2019-08-19 22:47 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-19 20:23 [PATCH v2 0/3] vmstats/vmevents flushing Roman Gushchin
2019-08-19 20:23 ` [PATCH v2 1/3] mm: memcontrol: flush percpu vmstats before releasing memcg Roman Gushchin
2019-08-19 20:23 ` [PATCH v2 2/3] mm: memcontrol: flush percpu slab vmstats on kmem offlining Roman Gushchin
2019-08-19 22:27 ` Andrew Morton
2019-08-19 22:46 ` Roman Gushchin [this message]
2019-08-19 20:23 ` [PATCH v2 3/3] mm: memcontrol: flush percpu vmevents before releasing memcg Roman Gushchin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190819224645.GA9473@tower.dhcp.thefacebook.com \
--to=guro@fb.com \
--cc=Kernel-team@fb.com \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=vdavydov.dev@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.