On 5/26/26 11:32, Prike Liang wrote: > 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.
Clear NAK. That handling is completely intentional like that and doesn't add any additional overhead. Regards, Christian. > > 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);
