Re: [RFC/POC PATCH 01/12] drm/amdgpu: add SVM UAPI definitions

["Christian König" <christian.koenig@amd.com>]

On 4/21/26 08:48, Matthew Brost wrote:
> On Tue, Apr 21, 2026 at 08:19:54AM +0200, Christian König wrote:
>> On 4/21/26 07:08, Matthew Brost wrote:
>>> On Mon, Apr 20, 2026 at 08:07:38PM +0200, Christian König wrote:
>>>> On 4/20/26 18:06, Matthew Brost wrote:
>>>>> On Mon, Apr 20, 2026 at 05:37:43PM +0200, Christian König wrote:
>>>>>> On 4/20/26 15:30, Huang, Honglei1 wrote:
>>>>>>> On 4/20/2026 8:15 PM, Christian König wrote:
>> ...
>>>> Either you set the information per-device and then each device only gets the information if it needs to migrate the page to it's own local memory or you have global information.
>>>>
>>>> So why does a device fd needs to know about remote pgmap?
>>>>
>>>
>>> Simplest example:
>>>
>>> Devices A and B. The user sets the preferred placement to Device A.
>>> Device B faults first, and Device B moves memory to Device A via remote
>>> pull and can access locally via P2P, scale-up, etc. Avoid a double
>>> bounce once Device A faults.
>>
>> So you basically tell the device as soon as you want to access this VA please push the underlying memory away to a different device?
>>
> 
> Yes. GPU SVM supports remote pulls.
> 
>> I didn't thought that would be a valid use case. As far as I can see the only thing you avoid is updating your page tables on the faulting device twice.
>>
> 
> TBH, I’m unsure if this will happen in practice, but it also seems
> entirely possible. Computers are asynchronous, have random thread
> stalls, etc., so out-of-order from expected access isn’t far-fetched.
> 
> No on 'updating your page tables twice' being only bad thing.
> 
> In my example, let’s say Device B moves memory to itself initially. Then
> Device A faults and tries to move the memory to itself.  
> 
> Bad things:
>  - Two copies (one from sys->Device B, then Device B -> A)
>  - Device B faults again after move to Device A - this stalls B's
>    execution pipeline

Yeah, I mean you can always shoot yourself into the foot if you give different devices contradicting information what to do on access.

But I think for this case you would tell device A to leave the buffer where it is and device B to migrate it locally on access.

So the worst thing which could happen is that device A accesses first, updates it page tables, then device B accesses, page tables of A get invalidated, and page migrated to device B. So at maximum you have one extra page table validation/invalidation.

When you tell both device A and B to migrate to local device memory the page will of course start to play ping/pong between the two devices on access.

The feature doesn't sound that useful, but on the other hand I guess drm_svm has already solved the pgmap lifetime issues resulting from that. So why not?

Thanks,
Christian.

> 
> Matt
> 
>> Thanks for the explanation, that was absolutely not obvious. Going to discuss that with the team on the next meeting.
>>
>> Christian.
>>
>>>
>>> Matt