From: Honglei Huang <[email protected]>
This series follows Christian's suggestions and builds on his earlier
fix work in the amdgpu VM critical section.
My understanding of all amdgpu VM locking details may be incomplete, so
review and confirmation from the VM maintainers would be appreciated.
It is described that the ordering problem and why both paths need the
same lock:
"Originally the notifier_lock only made sure that the CPU page table
updates were done in order and originally the eviction lock made sure
that the GPU page table updates were done in order, but essentially we
need the order for both.
The point is that the updates need to be serialized. In other words
when one CPU is doing a mapping operation and another CPU is doing an
unmap through an MMU notifier we somehow need to make sure that the
corresponding GPU page table updates execute in the correct order."
Before this series, the update flow uses two locks:
map thread:
notifier_lock (lock A)
validate range
pt_alloc drops only eviction_lock (lock B)
allocation enters direct reclaim
MMU notifier tries notifier_lock (lock A again)
deadlock here
The allocation cannot finish because reclaim waits for a read lock that
the same thread releases only after the allocation returns.
The VM helper also cannot drop and revalidate the notifier lock because
it only knows about the separate eviction lock.
After this series, all three paths use the same rwsem:
map thread:
unified notifier/eviction lock for read (lock A)
validate range
pt_alloc drops lock A
allocation can enter reclaim
MMU notifier can take lock A for write and finish
reacquire lock A for read
revalidate range
range valid -> update PTEs and PDEs -> publish the mapping
range changed -> return -EAGAIN and retry
MMU notifier / eviction:
unified notifier/eviction lock for write (lock A)
clear PTEs or evict page tables
The allocation no longer holds lock A during reclaim. If an MMU
notifier invalidates the range while lock A is dropped, the map thread
detects the changed range after reacquiring lock A and retries instead
of installing stale PTEs.
The three patches make the VM eviction lock read/write, support a
caller held lock with post allocation range revalidation, and use the
drm_gpusvm notifier lock for SVM VMs. Non SVM callers pass NULL and keep
the existing internal locking path.
The patches apply after the AMDGPU SVM build and VM fault-path
integration patch.
Testing:
MI60: KFD svm test passed, 2 known attribute failures (attribute get
refactor).
HIP catch_tests: 98% passed.
Honglei Huang (3):
drm/amdgpu: make VM eviction lock read/write to match notifier lock
drm/amdgpu: recheck range validity after page table allocation
drm/amdgpu: use drm_gpusvm notifier lock for VM eviction
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_svm.c | 37 ++++++--
drivers/gpu/drm/amd/amdgpu/amdgpu_svm_range.c | 52 +++++-------
drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 84 ++++++++++++-------
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 15 ++--
.../gpu/drm/amd/amdgpu/amdgpu_vm_internal.h | 30 ++++++-
drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c | 29 ++++++-
drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 7 +-
11 files changed, 176 insertions(+), 86 deletions(-)
--
2.34.1
