On Mon, Aug 19, 2019 at 03:27:44PM -0700, Andrew Morton wrote: > On Mon, 19 Aug 2019 13:23:37 -0700 Roman Gushchin <[email protected]> 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 <[email protected]> > > Cc: Johannes Weiner <[email protected]> > > Cc: Michal Hocko <[email protected]> > > Cc: Vladimir Davydov <[email protected]> > > [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!
