diff options
author | Felix Kuehling <Felix.Kuehling@amd.com> | 2023-10-27 18:21:55 -0400 |
---|---|---|
committer | Alex Deucher <alexander.deucher@amd.com> | 2023-11-29 16:49:23 -0500 |
commit | 9a1c1339abf972477aeef4ea037e650f49c5892d (patch) | |
tree | ad6e97f0185045197b24bab66c42b2746d6316da /drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c | |
parent | 4fc26c2f912b5d9232dc4432fb1b7bfd6f016be6 (diff) |
drm/amdkfd: Run restore_workers on freezable WQs
Make restore workers freezable so we don't have to explicitly flush them
in suspend and GPU reset code paths, and we don't accidentally try to
restore BOs while the GPU is suspended. Not having to flush restore_work
also helps avoid lock/fence dependencies in the GPU reset case where we're
not allowed to wait for fences.
A side effect of this is, that we can now have multiple concurrent threads
trying to signal the same eviction fence. Rework eviction fence signaling
and replacement to account for that.
The GPU reset path can no longer rely on restore_process_worker to resume
queues because evict/restore workers can run independently of it. Instead
call a new restore_process_helper directly.
This is an RFC and request for testing.
v2:
- Reworked eviction fence signaling
- Introduced restore_process_helper
v3:
- Handle unsignaled eviction fences in restore_process_bos
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Tested-by: Emily Deng <Emily.Deng@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Diffstat (limited to 'drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c')
0 files changed, 0 insertions, 0 deletions