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

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

On 11/13/26 21:56, Thomas Hellström wrote:
> On Fri, 2026-11-13 at 21:43 +0100, David Hildenbrand (Arm) wrote:
>> On 11/13/26 21:34, Thomas Hellström wrote:
>>> Hi, David
>>>
>>>
>>> There are two major problems with the current behaviour.
>>>
>>> 1) The work item executing hmm_range_fault() might have no affinity
>>> at
>>> all to the GPU about to access the memory.
>>>
>>> 2) If migration happens, then hmm_range_fault() will stop and retry
>>> leading to excessive execution time.
>>>
>>> While perhaps Matt's commit message doesn't correctly describe the
>>> GUP
>>> behaviour, do you have any alternative suggestion than to avoid
>>> migration in this case? I think it's a reasonable idea given the
>>> problems with the current code?
>>
>> Adding fault reasons that hack around NUMA hinting such that a actual
>> CPU
>> accessing it later will not trigger ... NUMA hinting?
>>
>> I might be missing the "reasonable" in here :P
> 
> Wouldn't the net effect be that content stays put instead of being
> migrated? In both cases a later CPU access will not trigger NUMA
> hinting except that the proposed change doesn't send content to an
> irrelevant node?

My point is that you are essentially disabling NUMA hinting because the CPU will
no longer trigger NUMA hinting faults.

But then, just disable it entirely. Maybe John knows what to do.

> 
>>
>> I recall that John (cc) kept saying "GPUs and NUMA balancing is
>> inherently
>> incompatible, you have to disable NUMA balancing".
> 
> Perhaps we could force hmm_range_fault() to run on the node closest to
> the GPU. Then at least the migration might be beneficial.

That's also true.

> 
>>
>> You could likely implement something similar to GUP, where you would
>> allow for
>> bypassing protnone for reading.
> 
> We could ofc look at that. Might help in some cases.
Would be interesting if that already solves most of your problem. Apparently for
KVM it did, but not sure why the write side was never that important.

-- 
Cheers,

David