Re: [PATCH v2 0/7] mm: batch rmap walks during large folio migration

["Garg, Shivank" <shivankg@amd.com>]

On Tue, 2026-11-10 at 16:08 -0800, Joanne Koong wrote:
> On Wed, Aug 12, 2026 at 9:24 PM Shivank Garg <shivankg@amd.com> wrote:
> > 
> > Migrating a PTE-mapped large folio currently walks the folio's rmap
> > one page at a time. It does so twice per migration:
> > 1. try_to_migrate_one(): Replace present PTEs with migration entries
> > 2. remove_migration_pte(): Restore migration entries to working PTEs.
> > 
> > For a folio with N contiguous PTEs, each walk repeats page_vma_mapped_walk()
> > and the associated operation per subpage of the folio. (256 iterations
> > for 1M folio).
> > 
> > This series enables both walks to process a batch of consecutive PTEs
> > that map the same large folio and do some refactoring and clean up on
> > the way.
> > 
> > Performance:
> > 
> > AMD EPYC ZEN 3, 2-socket system (1 node per socket).
> > move_pages() migrating 1 GB from node 0 -> node 1, throughput
> > in GB/s:
> >                        batch-         batch-restore
> > folio     vanilla       restore-only   + unmap         restore%   restore+unmap%
> > 4K        2.96±0.15     3.02±0.14      2.99±0.17         +2.2%    +1.0%
> > 64K       5.99±0.10     6.12±0.08      7.65±0.16         +2.2%   +27.7%
> > 256K      6.48±0.09     6.67±0.08      9.23±0.14         +2.9%   +42.4%
> > 1M        6.76±0.10     6.98±0.10      9.74±0.19         +3.1%   +44.0%
> > 2M       10.50±0.20    10.44±0.16     10.67±0.21         -0.5%    +1.6%
> > 
> > In plain migration, the folio copy itself dominates the cost, so these rmap walk
> > savings are only partly visible end-to-end.
> > 
> > When the folio copy is batched-copy and offloaded to DMA engine [1], the copy is
> > no longer the bottleneck and rmap-walk batching translates into much larger gains:
> > 
> > This series + [1], DMA Offload on PTDMA (DCBM), 16 channels:
> > 
> >                     batch-copy                      dcbm+restore
> > folio    vanilla    -offload(dcbm)  dcbm+restore    +unmap          (rmap batch impact)
> > 4K       3.05±0.13   2.76±0.11       2.77±0.12        2.74±0.09
> > 64K      5.85±0.11  10.66±0.27      11.56±1.45       17.55±0.56
> > 256K     6.26±0.08  13.64±2.73      13.68±0.16       34.76±0.57       (2.54x)
> > 1M       6.58±0.08  14.25±0.07      15.27±0.77       44.28±0.27       (3.11x)
> > 2M      10.61±0.24  65.26±0.96      65.25±1.65       65.66±0.87
> > 
> 
> Hi Shivank,
> 
> Are you planning to send a v3 of this series? My reason for asking is
> because batching the unmap also fixes an existing issue where when
> try_to_migrate_one() unmaps a PTE-mapped anon mTHP one PTE at a time,
> the folio looks partially mapped partway through and gets flagged for
> deferred split. My mTHP underused shrinker series [1] makes this more
> common since every underused mTHP split will now go through this path,
> which makes this bug a blocker for the series. More context can be
> found in [2], which was my attempt to fix this bug, but then David
> suggested we fix it in a better way by batching, and Zi pointed me to
> this series.
> 
> Thanks,
> Joanne
> 
> [1] https://lore.kernel.org/linux-mm/20261103212004.1356327-1-joannelkoong@gmail.com/
> [2] https://lore.kernel.org/linux-mm/20261109220958.2071687-1-joannelkoong@gmail.com/


Glad to hear this series helps your use case.

Yes, I'm working on v3. I slowed down on it because it depends on
Optimize anonymous large folio unmapping series [1], which hasn't been
merged yet.

If it helps, I can send v3 sooner, addressing the v2 comments, rebase
on the current tree, and split into unmap-side and restore-side series
for easier review.

[1] https://lore.kernel.org/linux-mm/20260924131106.1730494-1-dev.jain@arm.com/

Thanks,
Shivank