Re: [PATCH 00/12] [PATCH v14 00/12] migrate on fault for device pages

[Andrew Morton]

On Wed, 23 Sep 2026 08:29:34 +0300 Mika Penttilä <mpenttil@xxxxxxxxxx> wrote:

> 
> >> migration). It is also tricky to code correctly. One page table walk
> >> could costs over 1000 cpu cycles on X86-64, which is a significant hit.
> >>
> >> We should be able to walk the page table once, faulting
> >> pages in as required and replacing them with migration entries if
> >> requested.
> > Sounds sensible.
> >
> >> Tested in X86-64 VM with HMM test device, passing the selftests.
> >> For performance, the migrate throughput tests from the selftests
> >> show similar numbers (within error margin) as unmodified kernel.
> > But no performance benefits are demonstrated?
> 
> There are no performance regressions for current tests.
> Real benefits come if want to do migrate on fault.
> For migrate on fault today missing pages are collected as not-present and
> the caller has to fault them and re-run migrate_vma_setup(); folding 
> HMM_PFN_REQ_FAULT into the collecting walk removes that extra
> fault+retry round-trip, dropping two page table walks. Page table walks
> are not cheap. Not to mention simplified implementation for driver.
> Also, the vma looked up as part of the walk is readily available for
> migration, eliminating the need for explicit vma lookup - one more
> performance benefit. Net effect two saved page table walks and
> one vma lookup.

It certainly sounds that this series will result in performance
improvements, but have those improvements been quantified?

> This series also addresses the vanished/reborn page table while
> collecting problem which can crash current implementation.

Oh.  I didn't get that message from the v14 changelogs, and crashes in
the current implementation are not what we want.  In fact, addressing
those is more important than speeding things up.

Under what circumstances to these crashes occur?  Can/should we we fix
those in a minimal -stable backportable fashion before moving on to speedups?