[Intel-gfx] [RFC 03/13] drm/i915/svm: Runtime (RT) allocator support

[Niranjan Vishwanathapura]

On Thu, Nov 28, 2019 at 02:12:30PM +0200, Joonas Lahtinen wrote:
>Quoting Niranjan Vishwanathapura (2019-11-27 21:23:56)
>> >We should try to have the uAPI as final as early as possible. The
>> >change process is harder the later it is done, even for RFC :)
>> >
>> >On the same note, I'm inclined to have I915_SVM_MIGRATE called
>> >I915_GEM_VM_PREFAULT from the start, as I already have got some
>> >confused questions from folks who mix it with memory pressure
>> >initiated migration. And it's inherently racy as anybody could
>> >race with it, so PREFAULT would give an impression of that.
>> >
>> >And I think I915_GEM_VM_PREFAULT would be a generally applicable
>> >function, just like I915_GEM_VM_BIND. So we should use a struct
>> >member names that are close to I915_GEM_VM_BIND.
>> >
>> >Better ideas for name to emphasis the nature of what is being
>> >done? I915_GEM_VM_FAULT/I915_GEM_VM_{M,}ADVICE...
>> >
>>
>> Though current patchset only supports migrating pages from
>> host to device memory, I intend to support migrating from device
>> to host memory as well with same ioctl. User would want that.
>> Not sure what would be a good name then, _MIGRATE/_PREFETCH/_MOVE?
>
>In the HMM concept the CPU access would trigger fault, and trigger
>the transition, wouldn't it? But you're correct that it is kind of
>tied to the HMM concept, and may be confusing for BOs.
>

Yes it does. But I think we should give the user mechanism to explicitly
migrate/prefetch it back to system memory.

>_PREFETCH is a good suggestion for the term, which lead to
>discussion to avoid explosion of IOCTLs, Chris suggested
>consolidation, maybe we should have I915_GEM_VM_{M,}ADVISE?
>
>If we're looking at connections to fadvise(2), we're basically
>talking about equivalent of FADV_WILLNEED. That concept would
>be quite familiar to users. GEM_VM_{M,}ADVISE with WILLNEED
>and explicitly passing the memory region? Because we can't decipher
>that from the running thread like CPU.
>
>Thoughts?

Yah it is closer to mbind (instead of nodemask, we specify memory region/s).
So, I915_GEM_VM_MBIND? I am ok with _PREFETCH also.

>
>> Also, migrating gem objects is currently handled by separate ioctl
>> which is part of LMEM patch series. I am open to merging these
>> ioctls together (similart to VM_BIND) into a single MIGRATE ioctl.
>
>The IOCTL in the LMEM series is about setting the allowed backing
>store types of a BO, not about the residency. There was some
>discussion around doing explicit migrations by changing that list.
>Current thinking is that we only need to allow setting it once
>at creation. That also means it might be convertible to creation
>time only property.
>
>That'd eliminate the need for BO freeze IOCTL that was discussed
>with Mesa folks.
>

Ok.

Thanks,
Niranjana

>Regard, Joonas