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

[Joanne Koong]

On Wed, Aug 12, 2026 at 9:24 PM Shivank Garg <shivankg@xxxxxxx> 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@xxxxxxxxx/
[2] https://lore.kernel.org/linux-mm/20261109220958.2071687-1-joannelkoong@xxxxxxxxx/