From: Mika Penttilä <[email protected]> Currently, the way device page faulting and migration works is not optimal, if you want to do both fault handling and migration at once.
Being able to migrate not present pages (or pages mapped with incorrect permissions, eg. COW) to the GPU requires doing either of the following sequences: 1. hmm_range_fault() - fault in non-present pages with correct permissions, etc. 2. migrate_vma_*() - migrate the pages Or: 1. migrate_vma_*() - migrate present pages 2. If non-present pages detected by migrate_vma_*(): a) call hmm_range_fault() to fault pages in b) call migrate_vma_*() again to migrate now present pages The problem with the first sequence is that you always have to do two page walks even when most of the time the pages are present or zero page mappings so the common case takes a performance hit. The second sequence is better for the common case, but far worse if pages aren't present because now you have to walk the page tables three times (once to find the page is not present, once so hmm_range_fault() can find a non-present page to fault in and once again to setup the 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. Add a new flag to HMM APIs, HMM_PFN_REQ_MIGRATE, which tells to prepare for migration also during fault handling. For the migrate_vma_setup() call paths, new flags, MIGRATE_VMA_FAULT, and MIGRATE_VMA_WRITE are added to tell to add fault handling to migrate. An extra benefit of migrating with hmm_range_fault() path is the migrate_vma.vma gets populated, so no need to retrieve that separataly. This series avoids the problems in current collecting implementation, where racing MADV_DONTNEED could make the collecting arrays overflow. This is achieved mainly by having a rollback mechanism and populating the collecting array as the last step. Tested in X86-64 VM with HMM test device, passing the selftests. The migrate throughput tests from the selftests show similar numbers (within error margin) as an unmodified kernel, verifying not regressing with current workloads. For nouveau migrate-on-fault test harness was : Fedora 44, Mesa Rusticl, and a fine-grained-system-SVM OpenCL program. Nouveau SVM is opt-in via Mesa. The OpenCL program passes a plain malloc pointer (64 pages, array of integers) to the GPU. Increments each element on GPU, and verifies on the CPU the result. So it drives both directions of migration. With svm_migrate_on_fault=1, no migration at bind happens so it's full lazy. The GPU used in testing was Pascal generation GP102 (selected based on what nouveau supports for SVM). Tested also rebased on the "Remove device private pages from physical address space" series: https://lore.kernel.org/linux-mm/[email protected]/ plus a small patch to adjust with no problems. Changes in v16: - rebased to 7.3.0 (drm-tip) - addressed sashiko's concerns - added patch 12 - drm/nouveau/svm: add support for migrate on fault Sashiko's concerns : https://sashiko.dev/#/patchset/20260924065313.899730-1-mpenttil%40redhat.com patch 01 mm/Kconfig: changes for migrate on fault for device pages Q "Does selecting HMM_MIRROR under DEVICE_MIGRATION require an explicit dependency on MMU?" A A DEVICE_MIGRATION is def_bool MIGRATION && ZONE_DEVICE, and MIGRATION depends on MMU, which HMM_MIRROR also depends on. DEVICE_MIGRATION is not user selectable, and nothing selects it explicitly now. If some config would select it in the future, it should have MMU. patch 03 mm/hmm: preparations for HMM to participate in migration Q "This is not a bug, but could we add MIGRATE_VMA_SELECT_NONE to this enum under CONFIG_MIGRATION?" A Yes, added. patch 05 mm/hmm: migrate collection in HMM pagewalk - pte level Q "Can this cause a livelock when splitting the folio?" A the ref is taken under ptl before dropping it (no UAF), and the split either succeeds (progress) or fails -> HMM_PFN_ERROR + return 0 (termination). No unbounded retry, no livelock. The -EAGAIN -> goto again path only re-walks when state actually changed. Q "Does this code operate on uninitialized folio metadata if a driver maps an uninitialized compound page to userspace?" A The folio is either from vm_normal_page(), or a device private/coherent page and properly initialized so no. Q "Can a transient split failure result in valid pages being falsely marked as inaccessible?" A a split failure reports HMM_PFN_ERROR for that walk only; the consumer can re-fault and a later split can succeed. The page isn't lost or permanently marked. patch 06 mm/hmm: migrate collection in HMM pagewalk - pmd level Q "Can this lead to a use-after-free on an unlocked tail page?" A For that branch, it has to be fault folio. fault_page (of fault folio) is always device-private -> the tail new_fault_folio is a ZONE_DEVICE page, which reclaim never scans. So not possible. patch 08 mm/hmm: implement rollback for device page migration in HMM pagewalk Q "Will hmm_pfn_rollback_collected() destroy the user's per-PFN request flags?" A migration is entirely driven by default_flags, and (HMM_PFN_VALID|HMM_PFN_MIGRATE) is used as a sentinel for already pinned and migrate collected pfns. The sentinel is safe to be erased from per pfn flags. Q "Can this regression lead to memory corruption via an uninitialized PFN unlock/put?" A "rollback only unlocks/puts entries carrying the (HMM_PFN_VALID|HMM_PFN_MIGRATE) sentinel ,i.e. ones actually collected (locked+ref'd), so no uninitialized pfn is ever unlocked or put Q "Is there an infinite loop in hmm_range_fault_locked() when a THP split fails?" A yes, fixed in v16. A split failure now fills HMM_PFN_ERROR and returns 0 instead of -EBUSY patch 10 lib/test_hmm: add a new testcase for the migrate on fault Q "Will skipping the device page table update here create an inconsistent state that migrate_vma_finalize() permanently commits? (in case parallel unmap)" A Concurrent unmap is fine. In that case migrate_vma_finalize() frees dst pages, and retry migrates on next round. So no ping-pong, it is self-healing. Link to v15: https://lore.kernel.org/linux-mm/[email protected]/ Cc: David Hildenbrand <[email protected]> Cc: Jason Gunthorpe <[email protected]> Cc: Leon Romanovsky <[email protected]> Cc: Alistair Popple <[email protected]> Cc: Balbir Singh <[email protected]> Cc: Zi Yan <[email protected]> Cc: Matthew Brost <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Lorenzo Stoakes <[email protected]> Cc: "Liam R. Howlett" <[email protected]> Cc: Vlastimil Babka <[email protected]> Cc: Mike Rapoport <[email protected]> Cc: Suren Baghdasaryan <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Lyude Paul <[email protected]> Cc: Danilo Krummrich <[email protected]> Mika Penttilä (12): mm/Kconfig: changes for migrate on fault for device pages mm: add helper to convert HMM pfn to migrate pfn mm/hmm: preparations for HMM to participate in migration mm/hmm: do the plumbing for HMM to participate in migration mm/hmm: migrate collection in HMM pagewalk - pte level mm/hmm: migrate collection in HMM pagewalk - pmd level mm/hmm: add lazy MMU mode support for migration in HMM pagewalk mm/hmm: implement rollback for device page migration in HMM pagewalk mm: enable device page migration from HMM pagewalk lib/test_hmm: add a new testcase for the migrate on fault Documentation/mm/hmm: document migration through hmm_range_fault() drm/nouveau/svm: add support for migrate on fault Documentation/mm/hmm.rst | 39 + drivers/gpu/drm/nouveau/nouveau_dmem.c | 281 +++++++- drivers/gpu/drm/nouveau/nouveau_dmem.h | 12 + drivers/gpu/drm/nouveau/nouveau_svm.c | 141 ++-- drivers/gpu/drm/nouveau/nouveau_svm.h | 5 + include/linux/hmm.h | 51 +- include/linux/migrate.h | 59 +- lib/test_hmm.c | 174 ++++- lib/test_hmm_uapi.h | 21 +- mm/Kconfig | 1 + mm/hmm.c | 959 +++++++++++++++++++++++-- mm/migrate_device.c | 617 +++------------- tools/testing/selftests/mm/hmm-tests.c | 54 ++ 13 files changed, 1740 insertions(+), 674 deletions(-) drm-tip base-commit: b0311e0de50840c3f35aafa2e95c14bf38f4a767 -- 2.55.0
