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

[David Hildenbrand (Arm)]

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.

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.

-- 
Cheers,

David