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

[Matthew Brost <matthew.brost@intel.com>]

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

Matt

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