Re: [PATCH] mm/migrate_device: avoid overflowing migrate_vma collection arrays

[Zi Yan]

On 15 Jul 2026, at 8:40, David Hildenbrand (Arm) wrote:

> On 7/15/26 02:59, Zi Yan wrote:
>> On Tue Jul 14, 2026 at 1:30 AM EDT, Alistair Popple wrote:
>>> On 2026-07-14 at 10:10 +1000, Balbir Singh <balbirs@xxxxxxxxxx> wrote...
>>>>
>>>> I had a patch to add tracepoints to the code and some of that instrumentation
>>>> included this data. A combination of the trace points + hmm_tests will help us
>>>> get some data to start with.
>>>
>>> But hmm-test already has a nice bandwidth benchmark :) We just need to force
>>> the slow path. That used to be easier before I simplified the trylock handling
>>> but with the below patch applied I get quite a lot better perf from the
>>> optimisation. Note the patch isn't entirely correct as it assumes any locked
>>> page was locked by migrate_vma_collect_pmd but it's good enough for the purposes
>>> here.
>>
>> Thanks for the numbers. If I read them correctly, the optimization
>> has about 3x throughput of unoptimzied version. The optimization has to
>> stay.
>>
>> I will try to come up with a fix that resets collected PFNs, reverts
>> established migration entry along with putting folio ref, and restarts
>> from the beginning.
>
> IIUC, with the page table gone there are no entries to revert. We only have to
> take care of folio lock+ref.

You are right.

>
> Which raises a question: how can the page table be gone when it contained
> migration entries? Probably MADV_DONTNEED could clear them, followed by
> reclaiming the page table, maybe.

Yes, that is the case pointed out by Codex.

Best Regards,
Yan, Zi