[PATCH] mm: memcontrol: flush slab vmstats on kmem offlining

[PATCH] mm: memcontrol: flush slab vmstats on kmem offlining

[Roman Gushchin]

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>
---
 mm/memcontrol.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 51 insertions(+)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 3e821f34399f..3a5f6f486cdf 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -3412,6 +3412,50 @@ static int memcg_online_kmem(struct mem_cgroup *memcg)
 	return 0;
 }
 
+static void memcg_flush_slab_node_stats(struct mem_cgroup *memcg, int node)
+{
+	struct mem_cgroup_per_node *pn = memcg->nodeinfo[node];
+	struct mem_cgroup_per_node *pi;
+	unsigned long recl = 0, unrecl = 0;
+	int cpu;
+
+	for_each_possible_cpu(cpu) {
+		recl += raw_cpu_read(
+			pn->lruvec_stat_cpu->count[NR_SLAB_RECLAIMABLE]);
+		unrecl += raw_cpu_read(
+			pn->lruvec_stat_cpu->count[NR_SLAB_UNRECLAIMABLE]);
+	}
+
+	for (pi = pn; pi; pi = parent_nodeinfo(pi, node)) {
+		atomic_long_add(recl,
+				&pi->lruvec_stat[NR_SLAB_RECLAIMABLE]);
+		atomic_long_add(unrecl,
+				&pi->lruvec_stat[NR_SLAB_UNRECLAIMABLE]);
+	}
+}
+
+static void memcg_flush_slab_vmstats(struct mem_cgroup *memcg)
+{
+	struct mem_cgroup *mi;
+	unsigned long recl = 0, unrecl = 0;
+	int node, cpu;
+
+	for_each_possible_cpu(cpu) {
+		recl += raw_cpu_read(
+			memcg->vmstats_percpu->stat[NR_SLAB_RECLAIMABLE]);
+		unrecl += raw_cpu_read(
+			memcg->vmstats_percpu->stat[NR_SLAB_UNRECLAIMABLE]);
+	}
+
+	for (mi = memcg; mi; mi = parent_mem_cgroup(mi)) {
+		atomic_long_add(recl, &mi->vmstats[NR_SLAB_RECLAIMABLE]);
+		atomic_long_add(unrecl, &mi->vmstats[NR_SLAB_UNRECLAIMABLE]);
+	}
+
+	for_each_node(node)
+		memcg_flush_slab_node_stats(memcg, node);
+}
+
 static void memcg_offline_kmem(struct mem_cgroup *memcg)
 {
 	struct cgroup_subsys_state *css;
@@ -3432,7 +3476,14 @@ static void memcg_offline_kmem(struct mem_cgroup *memcg)
 	if (!parent)
 		parent = root_mem_cgroup;
 
+	/*
+	 * Deactivate and reparent kmem_caches. Then Flush percpu
+	 * slab statistics to have precise values at the parent and
+	 * all ancestor levels. It's required to keep slab stats
+	 * accurate after the reparenting of kmem_caches.
+	 */
 	memcg_deactivate_kmem_caches(memcg, parent);
+	memcg_flush_slab_vmstats(memcg);
 
 	kmemcg_id = memcg->kmemcg_id;
 	BUG_ON(kmemcg_id < 0);
-- 
2.21.0

Re: [PATCH] mm: memcontrol: flush slab vmstats on kmem offlining

[Andrew Morton]

On Thu, 8 Aug 2019 13:36:04 -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.
> 

Looks expensive.  How frequently can these functions be called?

> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -3412,6 +3412,50 @@ static int memcg_online_kmem(struct mem_cgroup *memcg)
>  	return 0;
>  }
>  
> +static void memcg_flush_slab_node_stats(struct mem_cgroup *memcg, int node)
> +{
> +	struct mem_cgroup_per_node *pn = memcg->nodeinfo[node];
> +	struct mem_cgroup_per_node *pi;
> +	unsigned long recl = 0, unrecl = 0;
> +	int cpu;
> +
> +	for_each_possible_cpu(cpu) {
> +		recl += raw_cpu_read(
> +			pn->lruvec_stat_cpu->count[NR_SLAB_RECLAIMABLE]);
> +		unrecl += raw_cpu_read(
> +			pn->lruvec_stat_cpu->count[NR_SLAB_UNRECLAIMABLE]);
> +	}
> +
> +	for (pi = pn; pi; pi = parent_nodeinfo(pi, node)) {
> +		atomic_long_add(recl,
> +				&pi->lruvec_stat[NR_SLAB_RECLAIMABLE]);
> +		atomic_long_add(unrecl,
> +				&pi->lruvec_stat[NR_SLAB_UNRECLAIMABLE]);
> +	}
> +}
> +
> +static void memcg_flush_slab_vmstats(struct mem_cgroup *memcg)
> +{
> +	struct mem_cgroup *mi;
> +	unsigned long recl = 0, unrecl = 0;
> +	int node, cpu;
> +
> +	for_each_possible_cpu(cpu) {
> +		recl += raw_cpu_read(
> +			memcg->vmstats_percpu->stat[NR_SLAB_RECLAIMABLE]);
> +		unrecl += raw_cpu_read(
> +			memcg->vmstats_percpu->stat[NR_SLAB_UNRECLAIMABLE]);
> +	}
> +
> +	for (mi = memcg; mi; mi = parent_mem_cgroup(mi)) {
> +		atomic_long_add(recl, &mi->vmstats[NR_SLAB_RECLAIMABLE]);
> +		atomic_long_add(unrecl, &mi->vmstats[NR_SLAB_UNRECLAIMABLE]);
> +	}
> +
> +	for_each_node(node)
> +		memcg_flush_slab_node_stats(memcg, node);

This loops across all possible CPUs once for each possible node.  Ouch.

Implementing hotplug handlers in here (which is surprisingly simple)
brings this down to num_online_nodes * num_online_cpus which is, I
think, potentially vastly better.

Re: [PATCH] mm: memcontrol: flush slab vmstats on kmem offlining

[Roman Gushchin]

On Thu, Aug 08, 2019 at 02:21:46PM -0700, Andrew Morton wrote:
> On Thu, 8 Aug 2019 13:36:04 -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.
> > 
> 
> Looks expensive.  How frequently can these functions be called?

Once per memcg lifetime.

> 
> > --- a/mm/memcontrol.c
> > +++ b/mm/memcontrol.c
> > @@ -3412,6 +3412,50 @@ static int memcg_online_kmem(struct mem_cgroup *memcg)
> >  	return 0;
> >  }
> >  
> > +static void memcg_flush_slab_node_stats(struct mem_cgroup *memcg, int node)
> > +{
> > +	struct mem_cgroup_per_node *pn = memcg->nodeinfo[node];
> > +	struct mem_cgroup_per_node *pi;
> > +	unsigned long recl = 0, unrecl = 0;
> > +	int cpu;
> > +
> > +	for_each_possible_cpu(cpu) {
> > +		recl += raw_cpu_read(
> > +			pn->lruvec_stat_cpu->count[NR_SLAB_RECLAIMABLE]);
> > +		unrecl += raw_cpu_read(
> > +			pn->lruvec_stat_cpu->count[NR_SLAB_UNRECLAIMABLE]);
> > +	}
> > +
> > +	for (pi = pn; pi; pi = parent_nodeinfo(pi, node)) {
> > +		atomic_long_add(recl,
> > +				&pi->lruvec_stat[NR_SLAB_RECLAIMABLE]);
> > +		atomic_long_add(unrecl,
> > +				&pi->lruvec_stat[NR_SLAB_UNRECLAIMABLE]);
> > +	}
> > +}
> > +
> > +static void memcg_flush_slab_vmstats(struct mem_cgroup *memcg)
> > +{
> > +	struct mem_cgroup *mi;
> > +	unsigned long recl = 0, unrecl = 0;
> > +	int node, cpu;
> > +
> > +	for_each_possible_cpu(cpu) {
> > +		recl += raw_cpu_read(
> > +			memcg->vmstats_percpu->stat[NR_SLAB_RECLAIMABLE]);
> > +		unrecl += raw_cpu_read(
> > +			memcg->vmstats_percpu->stat[NR_SLAB_UNRECLAIMABLE]);
> > +	}
> > +
> > +	for (mi = memcg; mi; mi = parent_mem_cgroup(mi)) {
> > +		atomic_long_add(recl, &mi->vmstats[NR_SLAB_RECLAIMABLE]);
> > +		atomic_long_add(unrecl, &mi->vmstats[NR_SLAB_UNRECLAIMABLE]);
> > +	}
> > +
> > +	for_each_node(node)
> > +		memcg_flush_slab_node_stats(memcg, node);
> 
> This loops across all possible CPUs once for each possible node.  Ouch.
> 
> Implementing hotplug handlers in here (which is surprisingly simple)
> brings this down to num_online_nodes * num_online_cpus which is, I
> think, potentially vastly better.
>

Hm, maybe I'm biased because we don't play much with offlining, and
don't have many NUMA nodes. What's the real world scenario? Disabling
hyperthreading?

Idk, given that it happens once per memcg lifetime, and memcg destruction
isn't cheap anyway, I'm not sure it worth it. But if you are, I'm happy
to add hotplug handlers.

I also thought about merging per-memcg stats and per-memcg-per-node stats
(reading part can aggregate over 2? 4? numa nodes each time). That will
make everything overall cheaper. But it's a separate topic.

Thanks!

Re: [PATCH] mm: memcontrol: flush slab vmstats on kmem offlining

[Andrew Morton]

On Thu, 8 Aug 2019 21:47:11 +0000 Roman Gushchin <guro@fb.com> wrote:

> On Thu, Aug 08, 2019 at 02:21:46PM -0700, Andrew Morton wrote:
> > On Thu, 8 Aug 2019 13:36:04 -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.
> > > 
> > 
> > Looks expensive.  How frequently can these functions be called?
> 
> Once per memcg lifetime.

iirc there are some workloads in which this can be rapid?

> > > +	for_each_node(node)
> > > +		memcg_flush_slab_node_stats(memcg, node);
> > 
> > This loops across all possible CPUs once for each possible node.  Ouch.
> > 
> > Implementing hotplug handlers in here (which is surprisingly simple)
> > brings this down to num_online_nodes * num_online_cpus which is, I
> > think, potentially vastly better.
> >
> 
> Hm, maybe I'm biased because we don't play much with offlining, and
> don't have many NUMA nodes. What's the real world scenario? Disabling
> hyperthreading?

I assume it's machines which could take a large number of CPUs but in
fact have few.  I've asked this in response to many patches down the
ages and have never really got a clear answer.

A concern is that if such machines do exist, it will take a long time
for the regression reports to get to us.  Especially if such machines
are rare.

> Idk, given that it happens once per memcg lifetime, and memcg destruction
> isn't cheap anyway, I'm not sure it worth it. But if you are, I'm happy
> to add hotplug handlers.

I think it's worth taking a look.  As I mentioned, it can turn out to
be stupidly simple.

> I also thought about merging per-memcg stats and per-memcg-per-node stats
> (reading part can aggregate over 2? 4? numa nodes each time). That will
> make everything overall cheaper. But it's a separate topic.