From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Song Hu <husong@kylinos.cn>
Cc: akpm@linux-foundation.org, apopple@nvidia.com, byungchul@sk.com,
gourry@gourry.net, joshua.hahnjy@gmail.com,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
matthew.brost@intel.com, ridong.chen@linux.dev, shivankg@amd.com,
willy@infradead.org, ying.huang@linux.alibaba.com,
ziy@nvidia.com
Subject: Re: [PATCH] mm/migrate: don't move memcg NR_FILE_PAGES for swapcache
Date: Thu, 12 Nov 2026 09:54:03 +0100 [thread overview]
Message-ID: <bfe69f54-9eda-454b-a764-7a9b185e2175@kernel.org> (raw)
In-Reply-To: <20261112024855.424402-1-husong@kylinos.cn>
On 11/12/26 03:48, Song Hu wrote:
>> On 11/10/26 04:09, Zi Yan wrote:
>>>
>>> It would be better to simplify the above like Joshua suggested.
>>>
>>>
>>> Like Joshua said in another email, it will be more readable if
>>> NR_SWAPCACHE updates can be moved into the then branch above.
>>
>> Can one of you write me the updated patch description? Thanks1
>
> Sure. Here's an updated commit message incorporating Joshua's
> suggestion to describe the accounting model first and then explain why
> migration gets it wrong.
>
> mm/migrate: don't move memcg NR_FILE_PAGES for swapcache
>
> NR_FILE_PAGES is accounted on both the node and memcg planes for page
> cache folios. Swapcache folios are the exception: they keep
> NR_FILE_PAGES only on the node plane, while their memcg accounting is
> tracked as NR_SWAPCACHE.
>
> The cross-zone path in __folio_migrate_mapping() currently migrates
> NR_FILE_PAGES through mod_lruvec_state(), which updates both planes.
> This is correct for normal page cache, but wrong for swapcache folios
> because there is no memcg NR_FILE_PAGES state to move. As a result,
> migration incorrectly increments the destination memcg counter and
> decrements the source one, leaving the per-memcg accounting incorrect
> until the memcg is destroyed.
>
> Reproducer, on a 2-node QEMU guest with cgroup v2:
>
> 1. create a cgroup with memory.max = 50M and swap enabled;
> 2. memset 128M of anonymous memory in it, so reclaim swaps most of
> it out;
> 3. fork to raise the swap entry refcount, then fault the memory
> back in, so the resident folios are swapcache ones;
> 4. migrate_pages(pid, node0 -> node1).
>
> "file" row of memory.numa_stat (bytes) after step 4:
>
> without this patch with this patch
> N0 N1 N0 N1
> 0 (*) 51691520 0 0
>
> (*) the source counter has gone negative; negative values read as 0.
>
> Fix it by updating the node accounting directly for swapcache folios
> while leaving the nonexistent memcg NR_FILE_PAGES state untouched.
> Non-swapcache folios continue to use mod_lruvec_state(), preserving
> the existing behaviour. This mirrors the existing swapcache handling
> for NR_SHMEM in the same block. It accompanies
> commit 4eef27af2932 ("mm/migrate: move NR_FILE_THPS on cross-node
> migration") and commit c5eef2e03618 ("mm/migrate: move
> NR_KERNEL_FILE_PAGES on cross-node migration").
>
> Reviewed-by: Joshua Hahn <joshua.hahnjy@gmail.com>
> Acked-by: Zi Yan <ziy@nvidia.com>
> Signed-off-by: Song Hu <husong@kylinos.cn>
>
> Thanks to Joshua and Zi for the helpful reviews.
Updated, thanks!
--
Cheers,
David
prev parent reply other threads:[~2026-11-12 8:54 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-04 4:43 [PATCH] mm/migrate: don't move memcg NR_FILE_PAGES for swapcache Song Hu
2026-11-04 15:54 ` Joshua Hahn
2026-11-05 10:10 ` David Hildenbrand (Arm)
2026-11-06 13:59 ` David Hildenbrand
2026-11-10 3:09 ` Zi Yan
2026-11-10 12:29 ` David Hildenbrand (Arm)
2026-11-12 2:48 ` Song Hu
2026-11-12 8:54 ` David Hildenbrand (Arm) [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bfe69f54-9eda-454b-a764-7a9b185e2175@kernel.org \
--to=david@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=byungchul@sk.com \
--cc=gourry@gourry.net \
--cc=husong@kylinos.cn \
--cc=joshua.hahnjy@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=matthew.brost@intel.com \
--cc=ridong.chen@linux.dev \
--cc=shivankg@amd.com \
--cc=willy@infradead.org \
--cc=ying.huang@linux.alibaba.com \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.