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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
