The userq signal path calls amdgpu_userq_ensure_ev_fence() for every emitted userq fence. That helper unconditionally flushed resume_work even when the current eviction fence was already valid and unsignaled. This adds expensive workqueue synchronization to the normal submit path.
Signed-off-by: Prike Liang <[email protected]> --- drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c index 38e310a8694d..f650d8d0ef53 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c @@ -412,8 +412,6 @@ amdgpu_userq_ensure_ev_fence(struct amdgpu_userq_mgr *uq_mgr, struct dma_fence *ev_fence; retry: - /* Flush any pending resume work to create ev_fence */ - flush_delayed_work(&uq_mgr->resume_work); mutex_lock(&uq_mgr->userq_mutex); ev_fence = amdgpu_evf_mgr_get_fence(evf_mgr); @@ -422,9 +420,12 @@ amdgpu_userq_ensure_ev_fence(struct amdgpu_userq_mgr *uq_mgr, mutex_unlock(&uq_mgr->userq_mutex); /* * Looks like there was no pending resume work, - * add one now to create a valid eviction fence + * add one now to create a valid eviction fence. + * Only flush the restore worker when the current eviction + * fence has already signaled and a new one needs to be rearmed. */ schedule_delayed_work(&uq_mgr->resume_work, 0); + flush_delayed_work(&uq_mgr->resume_work); goto retry; } dma_fence_put(ev_fence); -- 2.34.1
