On Wed, Sep 23, 2026 at 02:19:36PM -0700, 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? > > > 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.
Yeah, what is this about? The series still has lots of sashiko remarks, are they legit? Jason
