All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
To: Matthew Brost <matthew.brost@intel.com>
Cc: dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
	amd-gfx@lists.freedesktop.org, kernel-dev@igalia.com,
	"Christian König" <christian.koenig@amd.com>,
	"Danilo Krummrich" <dakr@kernel.org>,
	"Philipp Stanner" <phasta@kernel.org>
Subject: Re: [PATCH] drm/sched: Avoid double re-lock on the job free path
Date: Fri, 11 Jul 2025 13:39:26 +0100	[thread overview]
Message-ID: <30fec0b5-bd2f-44f7-906a-31d00a77ff63@igalia.com> (raw)
In-Reply-To: <aG6lTURGI2tVqRP+@lstrano-desk.jf.intel.com>



On 09/07/2025 18:22, Matthew Brost wrote:
> On Wed, Jul 09, 2025 at 11:49:44AM +0100, Tvrtko Ursulin wrote:
>>
>> On 09/07/2025 05:45, Matthew Brost wrote:
>>> On Tue, Jul 08, 2025 at 01:20:32PM +0100, 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 free 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@igalia.com>
>>>> Cc: Christian König <christian.koenig@amd.com>
>>>> Cc: Danilo Krummrich <dakr@kernel.org>
>>>> Cc: Matthew Brost <matthew.brost@intel.com>
>>>
>>> The patch looks correct, we do have CI failure in a section which
>>> stresses scheduling though. Probably noise though. Do you have Intel
>>> hardware? I suggest running xe_exec_threads in a loop on either LNL or
>>> BMG and see if the CI failure pops. If you don't have hardware, let me
>>> know and I can do this.
>>>
>>> With a bit of investigation in the CI failure:
>>> Reviewed-by: Matthew Brost <matthew.brost@intel.com>
>>
>> Thanks! I don't have the HW but I was able to press re-test in the CI so
>> lets see. Although at the moment I can't imagine a failure mode like that
>> could be caused by this patch.
>>
> 
> I ran xe_exec_threads in a loop 20x on BMG without a failure so CI issue
> seem unrelated.

Thanks!

Philipp - okay to merge this one?

Regards,

Tvrtko
> 
> Matt
> 
>> Regards,
>>
>> Tvrtko
>>
>>>
>>>> Cc: Philipp Stanner <phasta@kernel.org>
>>>> ---
>>>>    drivers/gpu/drm/scheduler/sched_main.c | 37 ++++++++++----------------
>>>>    1 file changed, 14 insertions(+), 23 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/scheduler/sched_main.c b/drivers/gpu/drm/scheduler/sched_main.c
>>>> index 1f077782ec12..1bce0b66f89c 100644
>>>> --- a/drivers/gpu/drm/scheduler/sched_main.c
>>>> +++ b/drivers/gpu/drm/scheduler/sched_main.c
>>>> @@ -366,22 +366,6 @@ static void __drm_sched_run_free_queue(struct drm_gpu_scheduler *sched)
>>>>    		queue_work(sched->submit_wq, &sched->work_free_job);
>>>>    }
>>>> -/**
>>>> - * drm_sched_run_free_queue - enqueue free-job work if ready
>>>> - * @sched: scheduler instance
>>>> - */
>>>> -static void drm_sched_run_free_queue(struct drm_gpu_scheduler *sched)
>>>> -{
>>>> -	struct drm_sched_job *job;
>>>> -
>>>> -	spin_lock(&sched->job_list_lock);
>>>> -	job = list_first_entry_or_null(&sched->pending_list,
>>>> -				       struct drm_sched_job, list);
>>>> -	if (job && dma_fence_is_signaled(&job->s_fence->finished))
>>>> -		__drm_sched_run_free_queue(sched);
>>>> -	spin_unlock(&sched->job_list_lock);
>>>> -}
>>>> -
>>>>    /**
>>>>     * drm_sched_job_done - complete a job
>>>>     * @s_job: pointer to the job which is done
>>>> @@ -1102,12 +1086,13 @@ drm_sched_select_entity(struct drm_gpu_scheduler *sched)
>>>>     * drm_sched_get_finished_job - fetch the next finished job to be destroyed
>>>>     *
>>>>     * @sched: scheduler instance
>>>> + * @have_more: are there more finished jobs on the list
>>>>     *
>>>>     * Returns the next finished job from the pending list (if there is one)
>>>>     * ready for it to be destroyed.
>>>>     */
>>>>    static struct drm_sched_job *
>>>> -drm_sched_get_finished_job(struct drm_gpu_scheduler *sched)
>>>> +drm_sched_get_finished_job(struct drm_gpu_scheduler *sched, bool *have_more)
>>>>    {
>>>>    	struct drm_sched_job *job, *next;
>>>> @@ -1115,22 +1100,25 @@ drm_sched_get_finished_job(struct drm_gpu_scheduler *sched)
>>>>    	job = list_first_entry_or_null(&sched->pending_list,
>>>>    				       struct drm_sched_job, list);
>>>> -
>>>>    	if (job && dma_fence_is_signaled(&job->s_fence->finished)) {
>>>>    		/* remove job from pending_list */
>>>>    		list_del_init(&job->list);
>>>>    		/* cancel this job's TO timer */
>>>>    		cancel_delayed_work(&sched->work_tdr);
>>>> -		/* make the scheduled timestamp more accurate */
>>>> +
>>>> +		*have_more = false;
>>>>    		next = list_first_entry_or_null(&sched->pending_list,
>>>>    						typeof(*next), list);
>>>> -
>>>>    		if (next) {
>>>> +			/* make the scheduled timestamp more accurate */
>>>>    			if (test_bit(DMA_FENCE_FLAG_TIMESTAMP_BIT,
>>>>    				     &next->s_fence->scheduled.flags))
>>>>    				next->s_fence->scheduled.timestamp =
>>>>    					dma_fence_timestamp(&job->s_fence->finished);
>>>> +
>>>> +			*have_more = dma_fence_is_signaled(&next->s_fence->finished);
>>>> +
>>>>    			/* start TO timer for next job */
>>>>    			drm_sched_start_timeout(sched);
>>>>    		}
>>>> @@ -1189,12 +1177,15 @@ static void drm_sched_free_job_work(struct work_struct *w)
>>>>    	struct drm_gpu_scheduler *sched =
>>>>    		container_of(w, struct drm_gpu_scheduler, work_free_job);
>>>>    	struct drm_sched_job *job;
>>>> +	bool have_more;
>>>> -	job = drm_sched_get_finished_job(sched);
>>>> -	if (job)
>>>> +	job = drm_sched_get_finished_job(sched, &have_more);
>>>> +	if (job) {
>>>>    		sched->ops->free_job(job);
>>>> +		if (have_more)
>>>> +			__drm_sched_run_free_queue(sched);
>>>> +	}
>>>> -	drm_sched_run_free_queue(sched);
>>>>    	drm_sched_run_job_queue(sched);
>>>>    }
>>>> -- 
>>>> 2.48.0
>>>>
>>


  reply	other threads:[~2025-07-11 12:39 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-08 12:20 [PATCH] drm/sched: Avoid double re-lock on the job free path Tvrtko Ursulin
2025-07-08 12:26 ` ✓ CI.KUnit: success for " Patchwork
2025-07-08 13:07 ` ✓ Xe.CI.BAT: " Patchwork
2025-07-08 14:28 ` ✗ Xe.CI.Full: failure " Patchwork
2025-07-09  4:45 ` [PATCH] " Matthew Brost
2025-07-09 10:49   ` Tvrtko Ursulin
2025-07-09 17:22     ` Matthew Brost
2025-07-11 12:39       ` Tvrtko Ursulin [this message]
2025-07-09 10:51 ` ✓ CI.KUnit: success for drm/sched: Avoid double re-lock on the job free path (rev2) Patchwork
2025-07-09 11:29 ` ✓ Xe.CI.BAT: " Patchwork
2025-07-09 12:54 ` ✓ Xe.CI.Full: " Patchwork
2025-07-11 13:04 ` [PATCH] drm/sched: Avoid double re-lock on the job free path Philipp Stanner
2025-07-11 15:11   ` Tvrtko Ursulin
  -- strict thread matches above, loose matches on Subject: below --
2025-07-16  8:51 Tvrtko Ursulin
2025-07-16 13:31 ` Maíra Canal
2025-07-16 13:49   ` Tvrtko Ursulin
2025-07-16 14:30     ` Maíra Canal
2025-07-16 14:46       ` Tvrtko Ursulin
2025-07-16 20:44         ` Maíra Canal
2025-07-18  7:13           ` Tvrtko Ursulin
2025-07-18  9:31             ` Philipp Stanner
2025-07-18  9:35               ` Tvrtko Ursulin
2025-07-18  9:41                 ` Philipp Stanner
2025-07-18 10:18                   ` Tvrtko Ursulin
2025-01-14 10:59 Tvrtko Ursulin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=30fec0b5-bd2f-44f7-906a-31d00a77ff63@igalia.com \
    --to=tvrtko.ursulin@igalia.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=christian.koenig@amd.com \
    --cc=dakr@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=kernel-dev@igalia.com \
    --cc=matthew.brost@intel.com \
    --cc=phasta@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.