On 2023-06-01 15:31, Philip Yang wrote:
To free page table BOs which are freed when updating page table, for
example PTE BOs when PDE0 used as PTE.
Signed-off-by: Philip Yang <Philip.Yang@xxxxxxx>
---
drivers/gpu/drm/amd/amdkfd/kfd_process.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
index af0a4b5257cc..0ff007a74d03 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
@@ -2101,6 +2101,11 @@ void kfd_flush_tlb(struct kfd_process_device *pdd, enum TLB_FLUSH_TYPE type)
amdgpu_amdkfd_flush_gpu_tlb_pasid(
dev->adev, pdd->process->pasid, type, xcc);
}
+
+ /* Signal page table fence to free page table BOs */
+ dma_fence_signal(vm->pt_fence);
+ dma_fence_put(vm->pt_fence);
+ vm->pt_fence = amdgpu_pt_fence_create();
This is a bit weird to create a fence here when we have no idea when it
will be signaled or whether it will be signaled at all. But I think it's
OK in this case. You add this fence to PT BOs before they get freed, and
at that point those BOs must wait for the next TLB flush before the BO
can be freed.
The only important thing is that fences in the same context get signaled
in the same order they are created. I think if you allocate a fence
context per VM, that should be guaranteed by the VM root reservation
lock that serializes all page table operations in the same VM.
You may need some locking here to prevent concurrent access to the fence
while you're signaling and replacing it.
Regards,
Felix
}
struct kfd_process_device *kfd_process_device_data_by_id(struct kfd_process *p, uint32_t gpu_id)
