From: Kiryl Shutsemau <kas@kernel.org>
To: "David Hildenbrand (Arm)" <david@kernel.org>
Cc: Wandun Chen <chenwandun1@gmail.com>,
hughd@google.com, akpm@linux-foundation.org, ziy@nvidia.com,
matthew.brost@intel.com, joshua.hahnjy@gmail.com,
byungchul@sk.com, gourry@gourry.net,
ying.huang@linux.alibaba.com, apopple@nvidia.com,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] mm/migrate: improve mlock tracking for PTE-mapped large folios
Date: Wed, 11 Nov 2026 19:01:55 +0000 [thread overview]
Message-ID: <avS7FfzvjieHufUE@thinkstation> (raw)
In-Reply-To: <5f9c449e-43b3-4732-9c14-8199418cace0@kernel.org>
On Wed, Nov 11, 2026 at 09:00:10AM +0100, David Hildenbrand (Arm) wrote:
> On 11/10/26 13:32, Wandun Chen wrote:
> > From: Wandun Chen <chenwandun@lixiang.com>
> >
> > Commit ab521b4142aa ("mm/rmap: improve mlock tracking for large folios")
> > mlocks a large folio when all its pages are added in one rmap operation.
> > However, when a PTE-mapped large folio is migrated, remove_migration_pte()
> > restores PTEs individually, passing nr_pages = 1 to the rmap helpers. As a
> > result, PG_mlocked is not set on the destination folio.
> >
> > Reclaim can restore mlock in try_to_unmap(), but Mlocked in /proc/meminfo
> > remains undercounted until that scan occurs.
> >
> > Restore mlock once the full mapping has been restored in a locked VMA
> > under one page table lock, rather than waiting for try_to_unmap() to
> > restore the mlock state.
> >
> > Signed-off-by: Wandun Chen <chenwandun@lixiang.com>
> > ---
> > mm/migrate.c | 10 +++++++++-
> > 1 file changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/mm/migrate.c b/mm/migrate.c
> > index 94033c222e04..140e291d4587 100644
> > --- a/mm/migrate.c
> > +++ b/mm/migrate.c
> > @@ -353,6 +353,7 @@ static bool remove_migration_pte(struct folio *folio,
> > {
> > struct rmap_walk_arg *rmap_walk_arg = arg;
> > DEFINE_FOLIO_VMA_WALK(pvmw, rmap_walk_arg->folio, vma, addr, PVMW_SYNC | PVMW_MIGRATION);
> > + unsigned long nr_ptes = 0;
> >
> > while (page_vma_mapped_walk(&pvmw)) {
> > rmap_t rmap_flags = RMAP_NONE;
> > @@ -446,9 +447,16 @@ static bool remove_migration_pte(struct folio *folio,
> > else
> > folio_add_file_rmap_pte(folio, new, vma);
> > set_pte_at(vma->vm_mm, pvmw.address, pvmw.pte, pte);
> > +
> > + nr_ptes++;
> > }
> > - if (READ_ONCE(vma->vm_flags) & VM_LOCKED)
> > + if (READ_ONCE(vma->vm_flags) & VM_LOCKED) {
> > + if (folio_test_large(folio) &&
> > + nr_ptes == folio_nr_pages(folio) &&
> > + !(pvmw.flags & PVMW_PGTABLE_CROSSED))
> > + mlock_vma_folio(folio, vma);
> > mlock_drain_local();
> > + }
> >
> > trace_remove_migration_pte(pvmw.address, pte_val(pte),
> > compound_order(new));
>
> I guess pte batching would be one way of handling it, but that requires more churn.
>
> The spirit is similar as in try_to_unmap_one(), where we count the number of
> ptes in one VMA. For consistency, I would call it "ptes".
>
> @Kiryl, can you take a look?
Looks right to me. Agreed on "ptes".
With that adjusted:
Reviewed-by: Kiryl Shutsemau (Meta) <kas@kernel.org>
>
> BTW, why don't we care about that in try_to_migrate?
try_to_migrate_one() unmaps the folio whether the VMA is VM_LOCKED or
not, so there is no mapping left to keep mlocked; removing the rmap
munlocks the source.
The mlock is rebuilt on the destination in remove_migration_ptes(),
which is the path this patch fixes.
--
Kiryl Shutsemau / Kirill A. Shutemov
next prev parent reply other threads:[~2026-11-11 19:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-10 12:32 [PATCH v2] mm/migrate: improve mlock tracking for PTE-mapped large folios Wandun Chen
2026-11-11 1:31 ` Wandun
2026-11-11 8:00 ` David Hildenbrand (Arm)
2026-11-11 19:01 ` Kiryl Shutsemau [this message]
2026-11-12 7:45 ` Wandun
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=avS7FfzvjieHufUE@thinkstation \
--to=kas@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=byungchul@sk.com \
--cc=chenwandun1@gmail.com \
--cc=david@kernel.org \
--cc=gourry@gourry.net \
--cc=hughd@google.com \
--cc=joshua.hahnjy@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=matthew.brost@intel.com \
--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.