Re: [Intel-xe] [PATCH v2 0/4] drm/xe: Support optional pinning of userptr pages

["Thomas Hellström" <thomas.hellstrom@linux.intel.com>]

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
>>