I'd been worried by high "swapcached" counts in memcg OOM reports,
thought we had a problem freeing swapcache, but it was just the
accounting that was wrong.

Two issues:

1. When __remove_mapping() removes swapcache, __delete_from_swap_cache()
relies on memcg_data for the right counts to be updated; but that had
already been reset by mem_cgroup_swapout().  Swap those calls around -
mem_cgroup_swapout() does not require the swapcached flag to be set.

6.1 commit ac35a4902374 ("mm: multi-gen LRU: minimal implementation")
already made a similar swap for workingset_eviction(), but not for this.

2. memcg's "swapcached" count was added for memcg v2 stats, but displayed
on OOM even for memcg v1: so mem_cgroup_move_account() ought to move it.

Fixes: b6038942480e ("mm: memcg: add swapcache stat for memcg v2")
Signed-off-by: Hugh Dickins <hughd@google.com>
---

 mm/memcontrol.c |    6 ++++++
 mm/vmscan.c     |    3 +--
 2 files changed, 7 insertions(+), 2 deletions(-)

--- 6.1-rc8/mm/memcontrol.c
+++ linux/mm/memcontrol.c
@@ -5741,6 +5741,12 @@ static int mem_cgroup_move_account(struc
 		}
 	}
 
+#ifdef CONFIG_SWAP
+	if (folio_test_swapcache(folio)) {
+		__mod_lruvec_state(from_vec, NR_SWAPCACHE, -nr_pages);
+		__mod_lruvec_state(to_vec, NR_SWAPCACHE, nr_pages);
+	}
+#endif
 	if (folio_test_writeback(folio)) {
 		__mod_lruvec_state(from_vec, NR_WRITEBACK, -nr_pages);
 		__mod_lruvec_state(to_vec, NR_WRITEBACK, nr_pages);
--- 6.1-rc8/mm/vmscan.c
+++ linux/mm/vmscan.c
@@ -1346,11 +1346,10 @@ static int __remove_mapping(struct addre
 	if (folio_test_swapcache(folio)) {
 		swp_entry_t swap = folio_swap_entry(folio);
 
-		/* get a shadow entry before mem_cgroup_swapout() clears folio_memcg() */
 		if (reclaimed && !mapping_exiting(mapping))
 			shadow = workingset_eviction(folio, target_memcg);
-		mem_cgroup_swapout(folio, swap);
 		__delete_from_swap_cache(folio, swap, shadow);
+		mem_cgroup_swapout(folio, swap);
 		xa_unlock_irq(&mapping->i_pages);
 		put_swap_folio(folio, swap);
 	} else {

On Sun, Dec 04, 2022 at 05:01:03PM -0800, Hugh Dickins wrote:
> I'd been worried by high "swapcached" counts in memcg OOM reports,
> thought we had a problem freeing swapcache, but it was just the
> accounting that was wrong.
> 
> Two issues:
> 
> 1. When __remove_mapping() removes swapcache, __delete_from_swap_cache()
> relies on memcg_data for the right counts to be updated; but that had
> already been reset by mem_cgroup_swapout().  Swap those calls around -
> mem_cgroup_swapout() does not require the swapcached flag to be set.
> 
> 6.1 commit ac35a4902374 ("mm: multi-gen LRU: minimal implementation")
> already made a similar swap for workingset_eviction(), but not for this.
> 
> 2. memcg's "swapcached" count was added for memcg v2 stats, but displayed
> on OOM even for memcg v1: so mem_cgroup_move_account() ought to move it.
> 
> Fixes: b6038942480e ("mm: memcg: add swapcache stat for memcg v2")
> Signed-off-by: Hugh Dickins <hughd@google.com>

Acked-by: Johannes Weiner <hannes@cmpxchg.org>

On Sun, Dec 4, 2022 at 5:01 PM Hugh Dickins <hughd@google.com> wrote:
>
> I'd been worried by high "swapcached" counts in memcg OOM reports,
> thought we had a problem freeing swapcache, but it was just the
> accounting that was wrong.
>
> Two issues:
>
> 1. When __remove_mapping() removes swapcache, __delete_from_swap_cache()
> relies on memcg_data for the right counts to be updated; but that had
> already been reset by mem_cgroup_swapout().  Swap those calls around -
> mem_cgroup_swapout() does not require the swapcached flag to be set.
>
> 6.1 commit ac35a4902374 ("mm: multi-gen LRU: minimal implementation")
> already made a similar swap for workingset_eviction(), but not for this.
>
> 2. memcg's "swapcached" count was added for memcg v2 stats, but displayed
> on OOM even for memcg v1: so mem_cgroup_move_account() ought to move it.
>
> Fixes: b6038942480e ("mm: memcg: add swapcache stat for memcg v2")
> Signed-off-by: Hugh Dickins <hughd@google.com>

Acked-by: Shakeel Butt <shakeelb@google.com>