On 9/24/26 00:19, Andrew Morton wrote:
> On Wed, 23 Sep 2026 08:29:34 +0300 Mika Penttilä <[email protected]> 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? Yes I think Alistair mentioned those walks showed clearly in perf traces in his experiments, and that served as a motivation for this series > >> 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? It is about races between concurrent MADV_DONTNEED and collecting, where the collecting arrays overflow if page table is cleared, recycled and reinstantiated as large page. I am not sure if there is minimal fix to all the corner cases, or would it be more like the approach in this series. --Mika
