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

From: Bingfang Guo

Date: Thu Sep 10 2026 - 03:42:23 EST


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@xxxxxxxxxx> 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