writeback: sum memcg dirty counters as needed

Since commit a983b5ebee57 ("mm: memcontrol: fix excessive complexity in memory.stat reporting") memcg dirty and writeback counters are managed as:
1) per-memcg per-cpu values in range of [-32..32]
2) per-memcg atomic counter
When a per-cpu counter cannot fit in [-32..32] it's flushed to the atomic. Stat readers only check the atomic.
Thus readers such as balance_dirty_pages() may see a nontrivial error
margin: 32 pages per cpu.
Assuming 100 cpus:
4k x86 page_size: 13 MiB error per memcg
64k ppc page_size: 200 MiB error per memcg
Considering that dirty+writeback are used together for some decisions the errors double.

This inaccuracy can lead to undeserved oom kills. One nasty case is when all per-cpu counters hold positive values offsetting an atomic negative value (i.e. per_cpu[*]=32, atomic=n_cpu*-32). balance_dirty_pages() only consults the atomic and does not consider throttling the next n_cpu*32 dirty pages. If the file_lru is in the 13..200 MiB range then there's absolutely no dirty throttling, which burdens vmscan with only dirty+writeback pages thus resorting to oom kill.

It could be argued that tiny containers are not supported, but it's more subtle. It's the amount the space available for file lru that matters. If a container has memory.max-200MiB of non reclaimable memory, then it will also suffer such oom kills on a 100 cpu machine.

...

Make balance_dirty_pages() and wb_over_bg_thresh() work harder to collect exact per memcg counters when a memcg is close to the throttling/writeback threshold. This avoids the aforementioned oom kills.

This does not affect the overhead of memory.stat, which still reads the single atomic counter.

Why not use percpu_counter? memcg already handles cpus going offline, so no need for that overhead from percpu_counter. And the percpu_counter spinlocks are more heavyweight than is required.

It probably also makes sense to include exact dirty and writeback counters in memcg oom reports. But that is saved for later.

Signed-off-by Greg Thelen <[email protected]>

include/linux/memcontrol.h +5 -0

@@ -573,6 +573,22 @@ static inline unsigned long memcg_page_state(struct mem_cgroup *memcg,
 	return x;
 }
 
+/* idx can be of type enum memcg_stat_item or node_stat_item */
+static inline unsigned long
+memcg_exact_page_state(struct mem_cgroup *memcg, int idx)
+{
+	long x = atomic_long_read(&memcg->stat[idx]);

Quoted 39 lines · On Thu, 7 Mar 2019 08:56:32 -0800 Greg Thelen <[email protected]> wrote:

Since commit a983b5ebee57 ("mm: memcontrol: fix excessive complexity in memory.stat reporting") memcg dirty and writeback counters are managed as:
1) per-memcg per-cpu values in range of [-32..32]
2) per-memcg atomic counter
When a per-cpu counter cannot fit in [-32..32] it's flushed to the atomic. Stat readers only check the atomic.
Thus readers such as balance_dirty_pages() may see a nontrivial error
margin: 32 pages per cpu.
Assuming 100 cpus:
4k x86 page_size: 13 MiB error per memcg
64k ppc page_size: 200 MiB error per memcg
Considering that dirty+writeback are used together for some decisions the errors double.

This inaccuracy can lead to undeserved oom kills. One nasty case is when all per-cpu counters hold positive values offsetting an atomic negative value (i.e. per_cpu[*]=32, atomic=n_cpu*-32). balance_dirty_pages() only consults the atomic and does not consider throttling the next n_cpu*32 dirty pages. If the file_lru is in the 13..200 MiB range then there's absolutely no dirty throttling, which burdens vmscan with only dirty+writeback pages thus resorting to oom kill.

It could be argued that tiny containers are not supported, but it's more subtle. It's the amount the space available for file lru that matters. If a container has memory.max-200MiB of non reclaimable memory, then it will also suffer such oom kills on a 100 cpu machine.

...

Make balance_dirty_pages() and wb_over_bg_thresh() work harder to collect exact per memcg counters when a memcg is close to the throttling/writeback threshold. This avoids the aforementioned oom kills.

This does not affect the overhead of memory.stat, which still reads the single atomic counter.

Quoted 6 lines

Why not use percpu_counter? memcg already handles cpus going offline, so no need for that overhead from percpu_counter. And the percpu_counter spinlocks are more heavyweight than is required.

It probably also makes sense to include exact dirty and writeback counters in memcg oom reports. But that is saved for later.

Nice changelog, thanks.

Quoted 1 line

Signed-off-by Greg Thelen <[email protected]>

Did you consider cc:stable for this? We may as well - the stablebots backport everything which might look slightly like a fix anyway :(

Quoted 16 lines

include/linux/memcontrol.h +10 -0

@@ -573,6 +573,22 @@ static inline unsigned long memcg_page_state(struct mem_cgroup *memcg,
 	return x;
 }
 
+/* idx can be of type enum memcg_stat_item or node_stat_item */
+static inline unsigned long
+memcg_exact_page_state(struct mem_cgroup *memcg, int idx)
+{
+	long x = atomic_long_read(&memcg->stat[idx]);
+#ifdef CONFIG_SMP
+	int cpu;
+
+	for_each_online_cpu(cpu)
+		x += per_cpu_ptr(memcg->stat_cpu, cpu)->count[idx];

include/linux/memcontrol.h static inline unsigned long memcg_page_state(struct mem_cgroup *memcg, · line 590

Quoted 5 lines

include/linux/memcontrol.h +5 -0

+	if (x < 0)
+		x = 0;
+#endif
+	return x;
+}

This looks awfully heavyweight for an inline function. Why not make it a regular function and avoid the bloat and i-cache consumption?

Also, did you instead consider making this spill the percpu counters into memcg->stat[idx]? That might be more useful for potential future callers. It would become a little more expensive though.

Since commit a983b5ebee57 ("mm: memcontrol: fix excessive complexity in memory.stat reporting") memcg dirty and writeback counters are managed as:
1) per-memcg per-cpu values in range of [-32..32]
2) per-memcg atomic counter
When a per-cpu counter cannot fit in [-32..32] it's flushed to the atomic. Stat readers only check the atomic.
Thus readers such as balance_dirty_pages() may see a nontrivial error
margin: 32 pages per cpu.
Assuming 100 cpus:
4k x86 page_size: 13 MiB error per memcg
64k ppc page_size: 200 MiB error per memcg
Considering that dirty+writeback are used together for some decisions the errors double.

This inaccuracy can lead to undeserved oom kills. One nasty case is when all per-cpu counters hold positive values offsetting an atomic negative value (i.e. per_cpu[*]=32, atomic=n_cpu*-32). balance_dirty_pages() only consults the atomic and does not consider throttling the next n_cpu*32 dirty pages. If the file_lru is in the 13..200 MiB range then there's absolutely no dirty throttling, which burdens vmscan with only dirty+writeback pages thus resorting to oom kill.

It could be argued that tiny containers are not supported, but it's more subtle. It's the amount the space available for file lru that matters. If a container has memory.max-200MiB of non reclaimable memory, then it will also suffer such oom kills on a 100 cpu machine.

The following test reliably ooms without this patch. This patch avoids oom kills.

...

Make balance_dirty_pages() and wb_over_bg_thresh() work harder to collect exact per memcg counters when a memcg is close to the throttling/writeback threshold. This avoids the aforementioned oom kills.

This does not affect the overhead of memory.stat, which still reads the single atomic counter.

Why not use percpu_counter? memcg already handles cpus going offline, so no need for that overhead from percpu_counter. And the percpu_counter spinlocks are more heavyweight than is required.

It probably also makes sense to include exact dirty and writeback counters in memcg oom reports. But that is saved for later.

Signed-off-by Greg Thelen <[email protected]>

---
 include/linux/memcontrol.h | 33 +++++++++++++++++++++++++--------
 mm/memcontrol.c            | 26 ++++++++++++++++++++------
 mm/page-writeback.c        | 27 +++++++++++++++++++++------
 3 files changed, 66 insertions(+), 20 deletions(-)

include/linux/memcontrol.h +0 -0

index 83ae11cbd12c..6a133c90138c 100644

Quoted 61 lines · Greg Thelen

Since commit a983b5ebee57 ("mm: memcontrol: fix excessive complexity in memory.stat reporting") memcg dirty and writeback counters are managed as:
1) per-memcg per-cpu values in range of [-32..32]
2) per-memcg atomic counter
When a per-cpu counter cannot fit in [-32..32] it's flushed to the atomic. Stat readers only check the atomic.
Thus readers such as balance_dirty_pages() may see a nontrivial error
margin: 32 pages per cpu.
Assuming 100 cpus:
4k x86 page_size: 13 MiB error per memcg
64k ppc page_size: 200 MiB error per memcg
Considering that dirty+writeback are used together for some decisions the errors double.

This inaccuracy can lead to undeserved oom kills. One nasty case is when all per-cpu counters hold positive values offsetting an atomic negative value (i.e. per_cpu[*]=32, atomic=n_cpu*-32). balance_dirty_pages() only consults the atomic and does not consider throttling the next n_cpu*32 dirty pages. If the file_lru is in the 13..200 MiB range then there's absolutely no dirty throttling, which burdens vmscan with only dirty+writeback pages thus resorting to oom kill.

It could be argued that tiny containers are not supported, but it's more subtle. It's the amount the space available for file lru that matters. If a container has memory.max-200MiB of non reclaimable memory, then it will also suffer such oom kills on a 100 cpu machine.

The following test reliably ooms without this patch. This patch avoids oom kills.

...

Make balance_dirty_pages() and wb_over_bg_thresh() work harder to collect exact per memcg counters when a memcg is close to the throttling/writeback threshold. This avoids the aforementioned oom kills.

This does not affect the overhead of memory.stat, which still reads the single atomic counter.

Why not use percpu_counter? memcg already handles cpus going offline, so no need for that overhead from percpu_counter. And the percpu_counter spinlocks are more heavyweight than is required.

It probably also makes sense to include exact dirty and writeback counters in memcg oom reports. But that is saved for later.

Signed-off-by Greg Thelen <[email protected]>

---
 include/linux/memcontrol.h | 33 +++++++++++++++++++++++++--------
 mm/memcontrol.c            | 26 ++++++++++++++++++++------
 mm/page-writeback.c        | 27 +++++++++++++++++++++------
 3 files changed, 66 insertions(+), 20 deletions(-)

include/linux/memcontrol.h +0 -0

index 83ae11cbd12c..6a133c90138c 100644

include/linux/memcontrol.h static inline unsigned long memcg_page_state(struct mem_cgroup *memcg, · line 574

Quoted 2 lines

include/linux/memcontrol.h +0 -0

@@ -573,6 +573,22 @@ static inline unsigned long memcg_page_state(struct mem_cgroup *memcg,
      return x;
 }

Hi Greg!

Thank you for the patch, definitely a good problem to be fixed!

Quoted 1 line

include/linux/memcontrol.h static inline unsigned long memcg_page_state(struct mem_cgroup *memcg, · line 581

Quoted 6 lines

include/linux/memcontrol.h +6 -0

+/* idx can be of type enum memcg_stat_item or node_stat_item */
+static inline unsigned long
+memcg_exact_page_state(struct mem_cgroup *memcg, int idx)
+{
+     long x = atomic_long_read(&memcg->stat[idx]);
+#ifdef CONFIG_SMP

I doubt that this #ifdef is correct without corresponding changes in __mod_memcg_state(). As now, we do use per-cpu buffer which spills to an atomic value event if !CONFIG_SMP. It's probably something that we want to change, but as now, #ifdef CONFIG_SMP should protect only "if (x < 0)" part.

Quoted 5 lines

include/linux/memcontrol.h +5 -0

+     int cpu;
+
+     for_each_online_cpu(cpu)
+             x += per_cpu_ptr(memcg->stat_cpu, cpu)->count[idx];
+     if (x < 0)

include/linux/memcontrol.h static inline unsigned long memcg_page_state(struct mem_cgroup *memcg, · line 590

Quoted 4 lines

include/linux/memcontrol.h +4 -0

+             x = 0;
+#endif
+     return x;
+}

Also, isn't it worth it to generalize memcg_page_state() instead? By adding an bool exact argument? I believe dirty balance is not the only place, where we need a better accuracy.

Quoted 14 lines · Roman Gushchin

include/linux/memcontrol.h static inline unsigned long memcg_page_state(struct mem_cgroup *memcg, · line 590

Quoted 9 lines · Greg Thelen

include/linux/memcontrol.h +9 -0

+     int cpu;
+
+     for_each_online_cpu(cpu)
+             x += per_cpu_ptr(memcg->stat_cpu, cpu)->count[idx];
+     if (x < 0)
+             x = 0;
+#endif
+     return x;
+}

Also, isn't it worth it to generalize memcg_page_state() instead? By adding an bool exact argument? I believe dirty balance is not the only place, where we need a better accuracy.

Nod. I'll provide a more general version of memcg_page_state(). I'm testing updated (forthcoming v2) patch set now with feedback from Andrew and Roman.

mm/memcontrol.c +18 -6

@@ -3880,6 +3880,7 @@ struct wb_domain *mem_cgroup_wb_domain(struct bdi_writeback *wb)
  * @pheadroom: out parameter for number of allocatable pages according to memcg
  * @pdirty: out parameter for number of dirty pages
  * @pwriteback: out parameter for number of pages under writeback
+ * @exact: determines exact counters are required, indicates more work.
  *
  * Determine the numbers of file, headroom, dirty, and writeback pages in
  * @wb's memcg.  File, dirty and writeback are self-explanatory.  Headroom

@@ -3890,18 +3891,29 @@ struct wb_domain *mem_cgroup_wb_domain(struct bdi_writeback *wb)
  * ancestors.  Note that this doesn't consider the actual amount of
  * available memory in the system.  The caller should further cap
  * *@pheadroom accordingly.
+ *
+ * Return value is the error precision associated with *@pdirty
+ * and *@pwriteback.  When @exact is set this a minimal value.
  */
-void mem_cgroup_wb_stats(struct bdi_writeback *wb, unsigned long *pfilepages,
-			 unsigned long *pheadroom, unsigned long *pdirty,
-			 unsigned long *pwriteback)
+unsigned long
+mem_cgroup_wb_stats(struct bdi_writeback *wb, unsigned long *pfilepages,
+		    unsigned long *pheadroom, unsigned long *pdirty,
+		    unsigned long *pwriteback, bool exact)
 {
 	struct mem_cgroup *memcg = mem_cgroup_from_css(wb->memcg_css);
 	struct mem_cgroup *parent;
+	unsigned long precision;
 
-	*pdirty = memcg_page_state(memcg, NR_FILE_DIRTY);
-
+	if (exact) {
+		precision = 0;
+		*pdirty = memcg_exact_page_state(memcg, NR_FILE_DIRTY);
+		*pwriteback = memcg_exact_page_state(memcg, NR_WRITEBACK);
+	} else {
+		precision = MEMCG_CHARGE_BATCH * num_online_cpus();
+		*pdirty = memcg_page_state(memcg, NR_FILE_DIRTY);
+		*pwriteback = memcg_page_state(memcg, NR_WRITEBACK);
+	}
 	/* this should eventually include NR_UNSTABLE_NFS */
-	*pwriteback = memcg_page_state(memcg, NR_WRITEBACK);
 	*pfilepages = mem_cgroup_nr_lru_pages(memcg, (1 << LRU_INACTIVE_FILE) |
 						     (1 << LRU_ACTIVE_FILE));
 	*pheadroom = PAGE_COUNTER_MAX;

Quoted 47 lines · Greg Thelen

mm/memcontrol.c +18 -6

@@ -3880,6 +3880,7 @@ struct wb_domain *mem_cgroup_wb_domain(struct bdi_writeback *wb)
  * @pheadroom: out parameter for number of allocatable pages according to memcg
  * @pdirty: out parameter for number of dirty pages
  * @pwriteback: out parameter for number of pages under writeback
+ * @exact: determines exact counters are required, indicates more work.
  *
  * Determine the numbers of file, headroom, dirty, and writeback pages in
  * @wb's memcg.  File, dirty and writeback are self-explanatory.  Headroom

@@ -3890,18 +3891,29 @@ struct wb_domain *mem_cgroup_wb_domain(struct bdi_writeback *wb)
  * ancestors.  Note that this doesn't consider the actual amount of
  * available memory in the system.  The caller should further cap
  * *@pheadroom accordingly.
+ *
+ * Return value is the error precision associated with *@pdirty
+ * and *@pwriteback.  When @exact is set this a minimal value.
  */
-void mem_cgroup_wb_stats(struct bdi_writeback *wb, unsigned long *pfilepages,
-			 unsigned long *pheadroom, unsigned long *pdirty,
-			 unsigned long *pwriteback)
+unsigned long
+mem_cgroup_wb_stats(struct bdi_writeback *wb, unsigned long *pfilepages,
+		    unsigned long *pheadroom, unsigned long *pdirty,
+		    unsigned long *pwriteback, bool exact)
 {
 	struct mem_cgroup *memcg = mem_cgroup_from_css(wb->memcg_css);
 	struct mem_cgroup *parent;
+	unsigned long precision;
 
-	*pdirty = memcg_page_state(memcg, NR_FILE_DIRTY);
-
+	if (exact) {
+		precision = 0;
+		*pdirty = memcg_exact_page_state(memcg, NR_FILE_DIRTY);
+		*pwriteback = memcg_exact_page_state(memcg, NR_WRITEBACK);
+	} else {
+		precision = MEMCG_CHARGE_BATCH * num_online_cpus();
+		*pdirty = memcg_page_state(memcg, NR_FILE_DIRTY);
+		*pwriteback = memcg_page_state(memcg, NR_WRITEBACK);
+	}
 	/* this should eventually include NR_UNSTABLE_NFS */
-	*pwriteback = memcg_page_state(memcg, NR_WRITEBACK);
 	*pfilepages = mem_cgroup_nr_lru_pages(memcg, (1 << LRU_INACTIVE_FILE) |
 						     (1 << LRU_ACTIVE_FILE));
 	*pheadroom = PAGE_COUNTER_MAX;

mm/memcontrol.c void mem_cgroup_wb_stats(struct bdi_writeback *wb, unsigned long *pfilepages, · line 3929

Quoted 5 lines

mm/memcontrol.c +2 -0

@@ -3913,6 +3925,8 @@ void mem_cgroup_wb_stats(struct bdi_writeback *wb, unsigned long *pfilepages,
 		*pheadroom = min(*pheadroom, ceiling - min(ceiling, used));
 		memcg = parent;
 	}
+
+	return precision;

Have you considered unconditionally using the exact version here?

It does for_each_online_cpu(), but until very, very recently we did this per default for all stats, for years. It only became a problem in conjunction with the for_each_memcg loops when frequently reading memory stats at the top of a very large hierarchy.

balance_dirty_pages() is called against memcgs that actually own the inodes/memory and doesn't do the additional recursive tree collection.

It's also not *that* hot of a function, and in the io path...

It would simplify this patch immensely.