| Message ID | 20230822162136.25895-1-thomas.hellstrom@linux.intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | drm/xe: Support optional pinning of userptr pages | expand |
Quoting Thomas Hellström (2023-08-22 19:21:32) > This series adds a flag at VM_BIND time to pin the memory backing a VMA. > Initially this is needed for long-running workloads on hardware that > neither support mid-thread preemption nor pagefaults, since without it > the userptr MMU notifier will wait for preemption until preemption times > out. From terminology perspective we have a lot of folks in the userspace and kernel developers who have come to understand pinned memory as something that is locked in place while a dependent context is active on the hardware. And that has been related to lack of page-fault support. As here the plan is to go a step forward and never move that memory, would it be worthy to call such memory LOCKED (would also align with CPU side). And per my understanding the aspiration is to keep supporting locking memory in place (within sysadmin configured limits) even if page-faults will become de-facto usage. So, in short, should we do s/pinned/locked/, to avoid terminology confusion between new and old drivers which userspace may have to deal from same codebase? Regards, Joonas > > Moving forward this could be supported also for bo-backed VMAs given > a proper accounting takes place. A sysadmin could then optionally configure > a system to be optimized for dealing with a single GPU application > at a time. > > The series will be followed up with an igt series to exercise the uAPI. > > v2: > - Address review comments by Matthew Brost. > > Thomas Hellström (4): > drm/xe/vm: Use onion unwind for xe_vma_userptr_pin_pages() > drm/xe/vm: Implement userptr page pinning > drm/xe/vm: Perform accounting of userptr pinned pages > drm/xe/uapi: Support pinning of userptr vmas > > drivers/gpu/drm/xe/xe_vm.c | 194 ++++++++++++++++++++++++------- > drivers/gpu/drm/xe/xe_vm.h | 9 ++ > drivers/gpu/drm/xe/xe_vm_types.h | 14 +++ > include/uapi/drm/xe_drm.h | 18 +++ > 4 files changed, 190 insertions(+), 45 deletions(-) > > -- > 2.41.0 >
Hi, On 9/8/23 10:44, Joonas Lahtinen wrote: > Quoting Thomas Hellström (2023-08-22 19:21:32) >> This series adds a flag at VM_BIND time to pin the memory backing a VMA. >> Initially this is needed for long-running workloads on hardware that >> neither support mid-thread preemption nor pagefaults, since without it >> the userptr MMU notifier will wait for preemption until preemption times >> out. > From terminology perspective we have a lot of folks in the userspace and > kernel developers who have come to understand pinned memory as something > that is locked in place while a dependent context is active on the > hardware. And that has been related to lack of page-fault support. > > As here the plan is to go a step forward and never move that memory, would > it be worthy to call such memory LOCKED (would also align with CPU side). > And per my understanding the aspiration is to keep supporting locking > memory in place (within sysadmin configured limits) even if page-faults > will become de-facto usage. > > So, in short, should we do s/pinned/locked/, to avoid terminology > confusion between new and old drivers which userspace may have to deal > from same codebase? This is mainly a problem for people used to i915 pinning where we at some point used the term "short term pinning" and "long term pinning". There are some discussions about the terminology here: https://lwn.net/Articles/600502/ although I'm not sure what the outcome of that patchset was, but in this patchset, we're at least using pin_user_pages() for these VMAS. TTM and dma-buf also uses the term pinning. The Linux distinction appears to be that locked pages are never paged out but may be migrated, (allowed to cause minor but not major pagefaults). Pinned pages are neither swapped nor migrated, and we're using the latter. So I think pinning is the correct terminology? (As a side note, Maarten was spending considerable time trying to remove the short term pinning from upstream i915 before xe work started). Anyway, this patch series is on hold until we've merged Xe and can follow up with a discussion on exactly how we can support pinning in drm. /Thomas > > Regards, Joonas > >> Moving forward this could be supported also for bo-backed VMAs given >> a proper accounting takes place. A sysadmin could then optionally configure >> a system to be optimized for dealing with a single GPU application >> at a time. >> >> The series will be followed up with an igt series to exercise the uAPI. >> >> v2: >> - Address review comments by Matthew Brost. >> >> Thomas Hellström (4): >> drm/xe/vm: Use onion unwind for xe_vma_userptr_pin_pages() >> drm/xe/vm: Implement userptr page pinning >> drm/xe/vm: Perform accounting of userptr pinned pages >> drm/xe/uapi: Support pinning of userptr vmas >> >> drivers/gpu/drm/xe/xe_vm.c | 194 ++++++++++++++++++++++++------- >> drivers/gpu/drm/xe/xe_vm.h | 9 ++ >> drivers/gpu/drm/xe/xe_vm_types.h | 14 +++ >> include/uapi/drm/xe_drm.h | 18 +++ >> 4 files changed, 190 insertions(+), 45 deletions(-) >> >> -- >> 2.41.0 >>