On Mon Sep 22, 2025 at 7:39 PM CEST, Christian König wrote:
On 22.09.25 17:30, Philipp Stanner wrote:
On Mon, 2025-09-22 at 15:09 +0200, Jules Maselbas wrote:
From: Tvrtko Ursulin tvrtko.ursulin@igalia.com
commit d42a254633c773921884a19e8a1a0f53a31150c3 upstream.
In FIFO mode (which is the default), both drm_sched_entity_push_job() and drm_sched_rq_update_fifo(), where the latter calls the former, are currently taking and releasing the same entity->rq_lock.
We can avoid that design inelegance, and also have a miniscule efficiency improvement on the submit from idle path, by introducing a new drm_sched_rq_update_fifo_locked() helper and pulling up the lock taking to its callers.
v2: * Remove drm_sched_rq_update_fifo() altogether. (Christian)
v3: * Improved commit message. (Philipp)
Signed-off-by: Tvrtko Ursulin tvrtko.ursulin@igalia.com Cc: Christian König christian.koenig@amd.com Cc: Alex Deucher alexander.deucher@amd.com Cc: Luben Tuikov ltuikov89@gmail.com Cc: Matthew Brost matthew.brost@intel.com Cc: Philipp Stanner pstanner@redhat.com Reviewed-by: Christian König christian.koenig@amd.com Signed-off-by: Philipp Stanner pstanner@redhat.com Link: https://patchwork.freedesktop.org/patch/msgid/20241016122013.7857-2-tursulin... (cherry picked from commit d42a254633c773921884a19e8a1a0f53a31150c3) Signed-off-by: Jules Maselbas jmaselbas@zdiv.net
Am I interpreting this mail correctly: you want to get this patch into stable?
Why? It doesn't fix a bug.
Patch #3 in this series depends on the other two, but I agree that isn't a good idea.
Yes patch #3 fixes a freeze in amdgpu
We should just adjust patch #3 to apply on the older kernel as well instead of backporting patches #1 and #2.
I initially modified patch #3 to use .rq_lock instead of .lock, but i didn't felt very confident with this modification. Should i sent a new version with a modified patch #3 ? If so, how the change should be reflected in the commit message ? (I initially ask #kernelnewbies but ended pulling the two other patches)
Best, Jules