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

[Dev Jain <dev.jain@arm.com>]

On 12/11/26 1:07 am, Garg, Shivank wrote:
> 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.

Hi, I was on vacation, I am going to send the next version of this soon.


> 
> 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