Re: [PATCH v5] mm/memcg: clear folio memcg after changing per memcg stats

[Bingfang Guo <bfguo@icloud.com>]

On Wed, Sep 09, 2026 at 10:59:04PM -0700, Andrew Morton wrote:
> On Thu, 10 Sep 2026 11:46:58 +0800 Bingfang Guo via B4 Relay <devnull+bingfangguo.tencent.com@kernel.org> wrote:
> 
>> I notice extremely high swapcached count in the per memcg level
>> memory.stat when running tests with cgroupv1 setup by swapping pages in
>> and out.  It seems that the counter never gets decreased so the value is
>> rather useless and confusing to users reading it. So I think fixing it
>> so that the value can reflect the actual swapcache usage correctly could
>> be helpful.
>> 
>> __memcg1_swapout() transfers the memsw charge of a folio to its swap
>> entry and clears folio->memcg_data as part of that.  In the vmscan
>> swapout path it runs before __swap_cache_del_folio(), which then
>> decrements the swapcache stats through lruvec_stat_mod_folio().  Since
>> folio->memcg_data has already been cleared, folio_memcg() returns NULL
>> and the NR_SWAPCACHE decrement only updates the node-level counter
>> instead of the memcg's lruvec, leaking the per-memcg swapcache count.
>> 
>> Move the __memcg1_swapout() call into __swap_cache_del_folio(), after
>> the NR_FILE_PAGES and NR_SWAPCACHE updates but before
>> __swap_cache_do_del_folio() removes the folio from the swap cache.  This
>> keeps the stats attributed to the folio's memcg while still recording
>> the swap cgroup with a valid folio->swap.  Add a swapout parameter so
>> the plain swap_cache_del_folio() path is left unchanged.
> 
> Thanks.
> 
>> Fixes: 2732acda82c9 ("mm, swap: use swap cache as the swap in synchronize layer")
> 
> January this year.
> 
> How does this affect users?  Should we backport the fix into earlier
> kernels?  If so, why?
> 

Thanks.

Users using swaps will read totally meaningless swapcache value
from per memcg memory.stat, like 200GB of swapcache on a 64GB
setup, which is quite confusing and may trigger monitoring
alerts, if any.

So I think we should backport this patch.  Although I don't
really know user space programs relying on this value to work, I
think it's always good to make sure that values provided by the
kernel are helpful and mean something.

Regards,
Bingfang