* Re: [PATCH] mm/migrate: move NR_FILE_THPS on cross-node migration
2026-10-25 11:02 [PATCH] mm/migrate: move NR_FILE_THPS on cross-node migration Ridong Chen
@ 2026-10-26 10:59 ` David Hildenbrand (Arm)
2026-10-26 12:51 ` Garg, Shivank
2026-10-27 5:08 ` Garg, Shivank
2026-10-27 14:57 ` Zi Yan
2 siblings, 1 reply; 6+ messages in thread
From: David Hildenbrand (Arm) @ 2026-10-26 10:59 UTC (permalink / raw)
To: Ridong Chen, Andrew Morton
Cc: Zi Yan, Matthew Brost, Joshua Hahn, Byungchul Park, Gregory Price,
Ying Huang, Alistair Popple, Matthew Wilcox (Oracle), linux-mm,
linux-kernel, Ridong Chen
On 10/25/26 12:02, Ridong Chen wrote:
> From: Ridong Chen <chenridong@xiaomi.com>
>
> When a page cache folio is migrated to another node,
> __folio_migrate_mapping() moves the per-node and per-memcg counters
> that are keyed off the folio's node: NR_FILE_PAGES, NR_SHMEM,
> NR_SHMEM_THPS, NR_SWAPCACHE and NR_FILE_DIRTY. NR_FILE_THPS is not
> moved, although __filemap_add_folio() charges it to the source node and
> filemap_unaccount_folio() takes it off whatever node the folio lives on
> when it is removed.
>
> Commit 0b52c420350e ("mm: fix shmem THP counters on migration") added
> the NR_SHMEM_THPS case but not its file-backed counterpart. Now that
> ext4, xfs, btrfs and erofs can all have PMD-sized page cache folios,
> migrating them via NUMA balancing, mbind(), migratepages, demotion or
> memory offlining leaks FileHugePages on the source node and underflows
> it on the destination, in both /sys/devices/system/node/nodeN/meminfo
> and memory.numa_stat. The global value is unaffected, which is why this
> went unnoticed.
>
> Reproducer, on a 2-node QEMU guest with THP set to "always":
>
> 1. read a 256M ext4 file through a MADV_HUGEPAGE mapping while bound
> to node 0, so its page cache is 128 PMD-sized folios on node 0;
> 2. move the mapping to node 1 with mbind(MPOL_MF_MOVE);
> 3. unmap the file and drop its page cache.
>
> nr_file_hugepages in /sys/devices/system/node/nodeN/vmstat after each
> step (in units of PMD-sized folios):
>
> without this patch with this patch
> node0 node1 node0 node1
> 1. cached 128 0 128 0
> 2. migrated 128 0 0 128
> 3. dropped 128 0 (*) 0 0
>
> (*) the counter has underflowed to -128; negative values read as 0.
>
> Without the patch the 128 folios stay accounted to node 0 forever, and
> every further round adds another 128. The same happens to the per-memcg
> per-node counter: after step 3, memory.stat of the cgroup shows
> "file_thp 0", while memory.numa_stat still shows
> "file_thp N0=268435456 N1=0". With the patch both are 0.
>
> Move NR_FILE_THPS together with NR_FILE_PAGES, using the same condition
> filemap_unaccount_folio() uses to take it off, so that THPs in the swap
> cache are left alone.
>
> Fixes: d68eccad3706 ("mm/filemap: Allow large folios to be added to the page cache")
> Signed-off-by: Ridong Chen <chenridong@xiaomi.com>
> ---
> Note: prepared with help from an LLM-based assistant (Kiro, claude-opus-5.5).
>
> mm/migrate.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/mm/migrate.c b/mm/migrate.c
> index 7bdcdb57652f..d55f576a2579 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -700,6 +700,10 @@ static int __folio_migrate_mapping(struct address_space *mapping,
> mod_lruvec_state(old_lruvec, NR_SHMEM_THPS, -nr);
> mod_lruvec_state(new_lruvec, NR_SHMEM_THPS, nr);
> }
> + } else if (!folio_test_swapbacked(folio) &&
> + folio_test_pmd_mappable(folio)) {
> + mod_lruvec_state(old_lruvec, NR_FILE_THPS, -nr);
> + mod_lruvec_state(new_lruvec, NR_FILE_THPS, nr);
> }
Looking at filemap_unaccount_folio(), I was (once again) surprise about the
different handling.
Key is that we might be migration aonymous folios in the swapcache.
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
--
Cheers,
David
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] mm/migrate: move NR_FILE_THPS on cross-node migration
2026-10-26 10:59 ` David Hildenbrand (Arm)
@ 2026-10-26 12:51 ` Garg, Shivank
2026-10-27 4:34 ` Ridong Chen
0 siblings, 1 reply; 6+ messages in thread
From: Garg, Shivank @ 2026-10-26 12:51 UTC (permalink / raw)
To: david@kernel.org, ridong.chen@linux.dev,
akpm@linux-foundation.org
Cc: chenridong@xiaomi.com, apopple@nvidia.com, ziy@nvidia.com,
gourry@gourry.net, linux-mm@kvack.org, matthew.brost@intel.com,
joshua.hahnjy@gmail.com, ying.huang@linux.alibaba.com,
linux-kernel@vger.kernel.org, byungchul@sk.com,
willy@infradead.org
On Mon, 2026-10-26 at 11:59 +0100, David Hildenbrand (Arm) wrote:
> On 10/25/26 12:02, Ridong Chen wrote:
> > From: Ridong Chen <chenridong@xiaomi.com>
> >
> > When a page cache folio is migrated to another node,
> > __folio_migrate_mapping() moves the per-node and per-memcg counters
> > that are keyed off the folio's node: NR_FILE_PAGES, NR_SHMEM,
> > NR_SHMEM_THPS, NR_SWAPCACHE and NR_FILE_DIRTY. NR_FILE_THPS is not
> > moved, although __filemap_add_folio() charges it to the source node and
> > filemap_unaccount_folio() takes it off whatever node the folio lives on
> > when it is removed.
> >
> > Commit 0b52c420350e ("mm: fix shmem THP counters on migration") added
> > the NR_SHMEM_THPS case but not its file-backed counterpart. Now that
> > ext4, xfs, btrfs and erofs can all have PMD-sized page cache folios,
> > migrating them via NUMA balancing, mbind(), migratepages, demotion or
> > memory offlining leaks FileHugePages on the source node and underflows
> > it on the destination, in both /sys/devices/system/node/nodeN/meminfo
> > and memory.numa_stat. The global value is unaffected, which is why this
> > went unnoticed.
> >
> > Reproducer, on a 2-node QEMU guest with THP set to "always":
> >
> > 1. read a 256M ext4 file through a MADV_HUGEPAGE mapping while bound
> > to node 0, so its page cache is 128 PMD-sized folios on node 0;
> > 2. move the mapping to node 1 with mbind(MPOL_MF_MOVE);
> > 3. unmap the file and drop its page cache.
> >
> > nr_file_hugepages in /sys/devices/system/node/nodeN/vmstat after each
> > step (in units of PMD-sized folios):
> >
> > without this patch with this patch
> > node0 node1 node0 node1
> > 1. cached 128 0 128 0
> > 2. migrated 128 0 0 128
> > 3. dropped 128 0 (*) 0 0
> >
> > (*) the counter has underflowed to -128; negative values read as 0.
> >
> > Without the patch the 128 folios stay accounted to node 0 forever, and
> > every further round adds another 128. The same happens to the per-memcg
> > per-node counter: after step 3, memory.stat of the cgroup shows
> > "file_thp 0", while memory.numa_stat still shows
> > "file_thp N0=268435456 N1=0". With the patch both are 0.
> >
> > Move NR_FILE_THPS together with NR_FILE_PAGES, using the same condition
> > filemap_unaccount_folio() uses to take it off, so that THPs in the swap
> > cache are left alone.
> >
> > Fixes: d68eccad3706 ("mm/filemap: Allow large folios to be added to the page cache")
> > Signed-off-by: Ridong Chen <chenridong@xiaomi.com>
> > ---
> > Note: prepared with help from an LLM-based assistant (Kiro, claude-opus-5.5).
> >
> > mm/migrate.c | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/mm/migrate.c b/mm/migrate.c
> > index 7bdcdb57652f..d55f576a2579 100644
> > --- a/mm/migrate.c
> > +++ b/mm/migrate.c
> > @@ -700,6 +700,10 @@ static int __folio_migrate_mapping(struct address_space *mapping,
> > mod_lruvec_state(old_lruvec, NR_SHMEM_THPS, -nr);
> > mod_lruvec_state(new_lruvec, NR_SHMEM_THPS, nr);
> > }
> > + } else if (!folio_test_swapbacked(folio) &&
> > + folio_test_pmd_mappable(folio)) {
> > + mod_lruvec_state(old_lruvec, NR_FILE_THPS, -nr);
> > + mod_lruvec_state(new_lruvec, NR_FILE_THPS, nr);
> > }
>
> Looking at filemap_unaccount_folio(), I was (once again) surprise about the
> different handling.
>
> Key is that we might be migration aonymous folios in the swapcache.
>
> Acked-by: David Hildenbrand (Arm) <david@kernel.org>
>
filemap_unaccount_folio() also checks for AS_KERNEL_FILE, but
__folio_migrate_mapping() does not.
Should add this as well?
Thanks,
Shivank
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] mm/migrate: move NR_FILE_THPS on cross-node migration
2026-10-26 12:51 ` Garg, Shivank
@ 2026-10-27 4:34 ` Ridong Chen
0 siblings, 0 replies; 6+ messages in thread
From: Ridong Chen @ 2026-10-27 4:34 UTC (permalink / raw)
To: Garg, Shivank, david@kernel.org, akpm@linux-foundation.org
Cc: chenridong@xiaomi.com, apopple@nvidia.com, ziy@nvidia.com,
gourry@gourry.net, linux-mm@kvack.org, matthew.brost@intel.com,
joshua.hahnjy@gmail.com, ying.huang@linux.alibaba.com,
linux-kernel@vger.kernel.org, byungchul@sk.com,
willy@infradead.org
On 10/26/2026 8:51 PM, Garg, Shivank wrote:
> On Mon, 2026-10-26 at 11:59 +0100, David Hildenbrand (Arm) wrote:
>> On 10/25/26 12:02, Ridong Chen wrote:
>>> From: Ridong Chen <chenridong@xiaomi.com>
>>>
>>> When a page cache folio is migrated to another node,
>>> __folio_migrate_mapping() moves the per-node and per-memcg counters
>>> that are keyed off the folio's node: NR_FILE_PAGES, NR_SHMEM,
>>> NR_SHMEM_THPS, NR_SWAPCACHE and NR_FILE_DIRTY. NR_FILE_THPS is not
>>> moved, although __filemap_add_folio() charges it to the source node and
>>> filemap_unaccount_folio() takes it off whatever node the folio lives on
>>> when it is removed.
>>>
>>> Commit 0b52c420350e ("mm: fix shmem THP counters on migration") added
>>> the NR_SHMEM_THPS case but not its file-backed counterpart. Now that
>>> ext4, xfs, btrfs and erofs can all have PMD-sized page cache folios,
>>> migrating them via NUMA balancing, mbind(), migratepages, demotion or
>>> memory offlining leaks FileHugePages on the source node and underflows
>>> it on the destination, in both /sys/devices/system/node/nodeN/meminfo
>>> and memory.numa_stat. The global value is unaffected, which is why this
>>> went unnoticed.
>>>
>>> Reproducer, on a 2-node QEMU guest with THP set to "always":
>>>
>>> 1. read a 256M ext4 file through a MADV_HUGEPAGE mapping while bound
>>> to node 0, so its page cache is 128 PMD-sized folios on node 0;
>>> 2. move the mapping to node 1 with mbind(MPOL_MF_MOVE);
>>> 3. unmap the file and drop its page cache.
>>>
>>> nr_file_hugepages in /sys/devices/system/node/nodeN/vmstat after each
>>> step (in units of PMD-sized folios):
>>>
>>> without this patch with this patch
>>> node0 node1 node0 node1
>>> 1. cached 128 0 128 0
>>> 2. migrated 128 0 0 128
>>> 3. dropped 128 0 (*) 0 0
>>>
>>> (*) the counter has underflowed to -128; negative values read as 0.
>>>
>>> Without the patch the 128 folios stay accounted to node 0 forever, and
>>> every further round adds another 128. The same happens to the per-memcg
>>> per-node counter: after step 3, memory.stat of the cgroup shows
>>> "file_thp 0", while memory.numa_stat still shows
>>> "file_thp N0=268435456 N1=0". With the patch both are 0.
>>>
>>> Move NR_FILE_THPS together with NR_FILE_PAGES, using the same condition
>>> filemap_unaccount_folio() uses to take it off, so that THPs in the swap
>>> cache are left alone.
>>>
>>> Fixes: d68eccad3706 ("mm/filemap: Allow large folios to be added to the page cache")
>>> Signed-off-by: Ridong Chen <chenridong@xiaomi.com>
>>> ---
>>> Note: prepared with help from an LLM-based assistant (Kiro, claude-opus-5.5).
>>>
>>> mm/migrate.c | 4 ++++
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/mm/migrate.c b/mm/migrate.c
>>> index 7bdcdb57652f..d55f576a2579 100644
>>> --- a/mm/migrate.c
>>> +++ b/mm/migrate.c
>>> @@ -700,6 +700,10 @@ static int __folio_migrate_mapping(struct address_space *mapping,
>>> mod_lruvec_state(old_lruvec, NR_SHMEM_THPS, -nr);
>>> mod_lruvec_state(new_lruvec, NR_SHMEM_THPS, nr);
>>> }
>>> + } else if (!folio_test_swapbacked(folio) &&
>>> + folio_test_pmd_mappable(folio)) {
>>> + mod_lruvec_state(old_lruvec, NR_FILE_THPS, -nr);
>>> + mod_lruvec_state(new_lruvec, NR_FILE_THPS, nr);
>>> }
>>
>> Looking at filemap_unaccount_folio(), I was (once again) surprise about the
>> different handling.
>>
>> Key is that we might be migration aonymous folios in the swapcache.
>>
>> Acked-by: David Hildenbrand (Arm) <david@kernel.org>
>>
>
> filemap_unaccount_folio() also checks for AS_KERNEL_FILE, but
> __folio_migrate_mapping() does not.
>
> Should add this as well?
>
Good catch, thanks. NR_KERNEL_FILE_PAGES has the same problem, and I
could reproduce it by demoting btrfs btree folios to a CPU-less memory
tier. Since it was introduced separately by e3a9ac4e866e ("mm: add
vmstat for kernel_file pages") and is a node-only counter, I sent it
as a separate patch on top of this one:
https://lore.kernel.org/20261027043214.2248986-1-ridong.chen@linux.dev
--
Best regards
Ridong
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] mm/migrate: move NR_FILE_THPS on cross-node migration
2026-10-25 11:02 [PATCH] mm/migrate: move NR_FILE_THPS on cross-node migration Ridong Chen
2026-10-26 10:59 ` David Hildenbrand (Arm)
@ 2026-10-27 5:08 ` Garg, Shivank
2026-10-27 14:57 ` Zi Yan
2 siblings, 0 replies; 6+ messages in thread
From: Garg, Shivank @ 2026-10-27 5:08 UTC (permalink / raw)
To: david@kernel.org, ridong.chen@linux.dev,
akpm@linux-foundation.org
Cc: chenridong@xiaomi.com, apopple@nvidia.com, ziy@nvidia.com,
gourry@gourry.net, linux-mm@kvack.org, matthew.brost@intel.com,
joshua.hahnjy@gmail.com, ying.huang@linux.alibaba.com,
linux-kernel@vger.kernel.org, byungchul@sk.com,
willy@infradead.org
On Sun, 2026-10-25 at 19:02 +0800, Ridong Chen wrote:
> From: Ridong Chen <chenridong@xiaomi.com>
>
> When a page cache folio is migrated to another node,
> __folio_migrate_mapping() moves the per-node and per-memcg counters
> that are keyed off the folio's node: NR_FILE_PAGES, NR_SHMEM,
> NR_SHMEM_THPS, NR_SWAPCACHE and NR_FILE_DIRTY. NR_FILE_THPS is not
> moved, although __filemap_add_folio() charges it to the source node and
> filemap_unaccount_folio() takes it off whatever node the folio lives on
> when it is removed.
>
> Commit 0b52c420350e ("mm: fix shmem THP counters on migration") added
> the NR_SHMEM_THPS case but not its file-backed counterpart. Now that
> ext4, xfs, btrfs and erofs can all have PMD-sized page cache folios,
> migrating them via NUMA balancing, mbind(), migratepages, demotion or
> memory offlining leaks FileHugePages on the source node and underflows
> it on the destination, in both /sys/devices/system/node/nodeN/meminfo
> and memory.numa_stat. The global value is unaffected, which is why this
> went unnoticed.
>
> Reproducer, on a 2-node QEMU guest with THP set to "always":
>
> 1. read a 256M ext4 file through a MADV_HUGEPAGE mapping while bound
> to node 0, so its page cache is 128 PMD-sized folios on node 0;
> 2. move the mapping to node 1 with mbind(MPOL_MF_MOVE);
> 3. unmap the file and drop its page cache.
>
> nr_file_hugepages in /sys/devices/system/node/nodeN/vmstat after each
> step (in units of PMD-sized folios):
>
> without this patch with this patch
> node0 node1 node0 node1
> 1. cached 128 0 128 0
> 2. migrated 128 0 0 128
> 3. dropped 128 0 (*) 0 0
>
> (*) the counter has underflowed to -128; negative values read as 0.
>
> Without the patch the 128 folios stay accounted to node 0 forever, and
> every further round adds another 128. The same happens to the per-memcg
> per-node counter: after step 3, memory.stat of the cgroup shows
> "file_thp 0", while memory.numa_stat still shows
> "file_thp N0=268435456 N1=0". With the patch both are 0.
>
> Move NR_FILE_THPS together with NR_FILE_PAGES, using the same condition
> filemap_unaccount_folio() uses to take it off, so that THPs in the swap
> cache are left alone.
>
> Fixes: d68eccad3706 ("mm/filemap: Allow large folios to be added to the page cache")
> Signed-off-by: Ridong Chen <chenridong@xiaomi.com>
> ---
> Note: prepared with help from an LLM-based assistant (Kiro, claude-opus-5.5).
>
> mm/migrate.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/mm/migrate.c b/mm/migrate.c
> index 7bdcdb57652f..d55f576a2579 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -700,6 +700,10 @@ static int __folio_migrate_mapping(struct address_space *mapping,
> mod_lruvec_state(old_lruvec, NR_SHMEM_THPS, -nr);
> mod_lruvec_state(new_lruvec, NR_SHMEM_THPS, nr);
> }
> + } else if (!folio_test_swapbacked(folio) &&
> + folio_test_pmd_mappable(folio)) {
> + mod_lruvec_state(old_lruvec, NR_FILE_THPS, -nr);
> + mod_lruvec_state(new_lruvec, NR_FILE_THPS, nr);
> }
> #ifdef CONFIG_SWAP
> if (folio_test_swapcache(folio)) {
>
> base-commit: bd1ecbb61afefc6a8b876ccbc31e9228b44e9eab
Looks good!
Reviewed-by: Shivank Garg <shivankg@amd.com>
Thanks,
Shivank
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] mm/migrate: move NR_FILE_THPS on cross-node migration
2026-10-25 11:02 [PATCH] mm/migrate: move NR_FILE_THPS on cross-node migration Ridong Chen
2026-10-26 10:59 ` David Hildenbrand (Arm)
2026-10-27 5:08 ` Garg, Shivank
@ 2026-10-27 14:57 ` Zi Yan
2 siblings, 0 replies; 6+ messages in thread
From: Zi Yan @ 2026-10-27 14:57 UTC (permalink / raw)
To: Ridong Chen
Cc: Andrew Morton, David Hildenbrand, Matthew Brost, Joshua Hahn,
Byungchul Park, Gregory Price, Ying Huang, Alistair Popple,
Matthew Wilcox (Oracle), linux-mm, linux-kernel, Ridong Chen
On 25 Oct 2026, at 7:02, Ridong Chen wrote:
> From: Ridong Chen <chenridong@xiaomi.com>
>
> When a page cache folio is migrated to another node,
> __folio_migrate_mapping() moves the per-node and per-memcg counters
> that are keyed off the folio's node: NR_FILE_PAGES, NR_SHMEM,
> NR_SHMEM_THPS, NR_SWAPCACHE and NR_FILE_DIRTY. NR_FILE_THPS is not
> moved, although __filemap_add_folio() charges it to the source node and
> filemap_unaccount_folio() takes it off whatever node the folio lives on
> when it is removed.
>
> Commit 0b52c420350e ("mm: fix shmem THP counters on migration") added
> the NR_SHMEM_THPS case but not its file-backed counterpart. Now that
> ext4, xfs, btrfs and erofs can all have PMD-sized page cache folios,
> migrating them via NUMA balancing, mbind(), migratepages, demotion or
> memory offlining leaks FileHugePages on the source node and underflows
> it on the destination, in both /sys/devices/system/node/nodeN/meminfo
> and memory.numa_stat. The global value is unaffected, which is why this
> went unnoticed.
>
> Reproducer, on a 2-node QEMU guest with THP set to "always":
>
> 1. read a 256M ext4 file through a MADV_HUGEPAGE mapping while bound
> to node 0, so its page cache is 128 PMD-sized folios on node 0;
> 2. move the mapping to node 1 with mbind(MPOL_MF_MOVE);
> 3. unmap the file and drop its page cache.
>
> nr_file_hugepages in /sys/devices/system/node/nodeN/vmstat after each
> step (in units of PMD-sized folios):
>
> without this patch with this patch
> node0 node1 node0 node1
> 1. cached 128 0 128 0
> 2. migrated 128 0 0 128
> 3. dropped 128 0 (*) 0 0
>
> (*) the counter has underflowed to -128; negative values read as 0.
>
> Without the patch the 128 folios stay accounted to node 0 forever, and
> every further round adds another 128. The same happens to the per-memcg
> per-node counter: after step 3, memory.stat of the cgroup shows
> "file_thp 0", while memory.numa_stat still shows
> "file_thp N0=268435456 N1=0". With the patch both are 0.
>
> Move NR_FILE_THPS together with NR_FILE_PAGES, using the same condition
> filemap_unaccount_folio() uses to take it off, so that THPs in the swap
> cache are left alone.
>
> Fixes: d68eccad3706 ("mm/filemap: Allow large folios to be added to the page cache")
> Signed-off-by: Ridong Chen <chenridong@xiaomi.com>
> ---
> Note: prepared with help from an LLM-based assistant (Kiro, claude-opus-5.5).
>
> mm/migrate.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
LGTM. Thanks.
Acked-by: Zi Yan <ziy@nvidia.com>
Best Regards,
Yan, Zi
^ permalink raw reply [flat|nested] 6+ messages in thread