[PATCH v2] drm/sched: Avoid double re-lock on the job free path

[Tvrtko Ursulin]

On 12/07/2025 14:12, Maíra Canal wrote:
> Hi Danilo,
> 
> On 7/11/25 16:22, Danilo Krummrich wrote:
>> On 7/11/25 9:08 PM, Maíra Canal wrote:
>>> Hi Tvrtko,
>>>
>>> On 11/07/25 12:09, Tvrtko Ursulin wrote:
>>>> Currently the job free work item will lock sched->job_list_lock 
>>>> first time
>>>> to see if there are any jobs, free a single job, and then lock again to
>>>> decide whether to re-queue itself if there are more finished jobs.
>>>>
>>>> Since drm_sched_get_finished_job() already looks at the second job 
>>>> in the
>>>> queue we can simply add the signaled check and have it return the 
>>>> presence
>>>> of more jobs to be freed to the caller. That way the work item does not
>>>> have to lock the list again and repeat the signaled check.
>>>>
>>>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin at igalia.com>
>>>> Cc: Christian König <christian.koenig at amd.com>
>>>> Cc: Danilo Krummrich <dakr at kernel.org>
>>>> Cc: Matthew Brost <matthew.brost at intel.com>
>>>> Cc: Philipp Stanner <phasta at kernel.org>
>>>> ---
>>>> v2:
>>>>   * Improve commit text and kerneldoc. (Philipp)
>>>>   * Rename run free work helper. (Philipp)
>>>
>>> Maybe, would it be possible not to rename it? Otherwise, I won't be able
>>> to use the function name `drm_sched_run_free_queue()` in the
>>> DRM_GPU_SCHED_STAT_NO_HANG series.
>>>
>>> Not a big deal, but it would ease reintroducing
>>> `drm_sched_run_free_queue()` if the series lands after this patch.
>>
>> Do you intend to land your series through a different tree?
> 
> No, I plan to land my series in drm-misc-next. I'm just waiting our
> discussion with König to settle down before pushing it. However, if
> Tvrtko doesn't mind, we can arrange to push this patch after my series.
> 
> But again, not a big deal, I can rebase it later.

Your series has more patches, and is more important, so I am fine to 
wait a few days and rebase after you land it.

Regards,

Tvrtko