Re: [PATCH] mm/hmm: skip NUMA balancing on protnone faults

["David Hildenbrand (Arm)" <david@kernel.org>]

On 11/13/26 17:25, Matthew Auld wrote:
> When automatic NUMA balancing marks a PTE or PMD as protnone
> (PAGE_NONE), hmm_pte_need_fault() requests a fault to restore access
> permissions, including _PAGE_RW when write access is needed.
> 
> Calling handle_mm_fault() from hmm_do_fault() currently triggers NUMA
> balancing in do_numa_page() and do_huge_pmd_numa_page(). When
> hmm_range_fault() runs from a device driver or kworker context (such as
> a GPU SVM or userptr rebind worker), folios get migrated toward the CPU
> node executing the remote fault.
> 
> Also, each folio migration invokes try_to_migrate_one() ->
> mmu_notifier_invalidate_range_start(), which invalidates the
> caller's mmu_interval_notifier while holding mmap_lock. That causes
> hmm_range_fault() to abort with -EBUSY after every 2 MiB PMD and exhaust
> its retry timeout on large buffers, which has been observed with large
> imported Xe userptr buffers.
> 
> Add FAULT_FLAG_NO_NUMA and set it in hmm_do_fault() so protnone entries
> restore PTE/PMD permissions in-place without performing NUMA balancing,
> matching GUP's default !FOLL_HONOR_NUMA_FAULT behaviour.

Ehm, that's not how it works.

GUP will not trigger a "special" fault and will try not triggering a fault and
not restore permissions.

It will try continuing, leaving the protnone pte as it is.

See gup_can_follow_protnone().

For read-only access that should always work.

For write-access we always trigger an ordinary fault and do NUMA migration etc.


So FAULT_FLAG_NO_NUMA is doing something completely different and I don't agree
with it.


-- 
Cheers,

David