dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Philipp Stanner <phasta@mailbox.org>
To: "Christian König" <christian.koenig@amd.com>,
	phasta@kernel.org, "Lin.Cao" <lincao12@amd.com>,
	dri-devel@lists.freedesktop.org
Cc: zhenguo.yin@amd.com, Emily.Deng@amd.com, dakr@kernel.org,
	 matthew.brost@intel.com
Subject: Re: [PATCH v2] drm/scheduler: Fix sched hang when killing app with dependent jobs
Date: Mon, 14 Jul 2025 15:27:21 +0200	[thread overview]
Message-ID: <70d9c6a43846c3a3c266d4a7a431c1c4b3fcd05f.camel@mailbox.org> (raw)
In-Reply-To: <a8e473bd-6ea8-41e0-b5b2-10c420e5a935@amd.com>

On Mon, 2025-07-14 at 15:08 +0200, Christian König wrote:
> 
> 
> On 14.07.25 14:46, Philipp Stanner wrote:
> > regarding the patch subject: the prefix we use for the scheduler
> > is:
> > drm/sched:
> > 
> > 
> > On Mon, 2025-07-14 at 14:23 +0800, Lin.Cao wrote:
> > 
> > > When Application A submits jobs (a1, a2, a3) and application B
> > > submits
> > 
> > s/Application/application
> > 
> > > job b1 with a dependency on a2's scheduler fence, killing
> > > application A
> > > before run_job(a1) causes drm_sched_entity_kill_jobs_work() to
> > > force
> > > signal all jobs sequentially. However, due to missing
> > > work_run_job or
> > > work_free_job
> > > 
> > 
> > You probably mean "due to the work items work_run_job and
> > work_free_job
> > not being started […]".
> > 
> > However, the call you add, drm_sched_wakeup(), immediately only
> > triggers work_run_job. It's not clear to me why you mention
> > work_free_job, because drm_sched_entity_kill_jobs_work() directly
> > invokes the free_job() callback.
> 
> Yeah the description is rather confusing, took me more than one try
> to understand what's going on here as well. Let me try to explain it
> in my words:
> 
> When an application A is killed the pending submissions from it are
> not executed, but rather torn down by
> drm_sched_entity_kill_jobs_work().
> 
> If now a submission from application B depends on something
> application A wanted to do on the same scheduler instance the
> function drm_sched_entity_add_dependency_cb() would have optimized
> this dependency and assumed that the scheduler work would already run
> and try to pick a job.
> 
> But that isn't the case when the submissions from application A are
> all killed. So make sure to start the scheduler work from
> drm_sched_entity_kill_jobs_work() to handle that case.

Alright, so the bug then depends on B setting a dependency on A _after_
A was killed, doesn't it? Because the optimization in
_add_dependency_cb() can only have an effect after A's jobs have been
torn down.

If there is such a timing order problem, the commit message should
mention it.

The commit message definitely also needs to mention this optimization
in drm_sched_entity_add_dependency_cb() since it's essential for
understanding the bug.


Danke
P.


> 
> Regards,
> Christian.
> 
> > 
> > >  in entity_kill_job_work(), the scheduler enters sleep
> > > state, causing application B hang.
> > 
> > So the issue is that if a1 never ran, the scheduler will not
> > continue
> > with the jobs of application B, correct?
> > 
> > > 
> > > Add drm_sched_wakeup() when entity_kill_job_work() to preventing
> > 
> > s/to preventing/to prevent
> > 
> > > scheduler sleep and subsequent application hangs.
> > > 
> > > v2:
> > > - Move drm_sched_wakeup() to after drm_sched_fence_scheduled()
> > 
> > Changelogs are cool and useful, but move them below the Signed-off
> > area
> > with another --- please, like so:
> > 
> > Signed-off by: …
> > ---
> > v2:
> > …
> > ---
> > drivers/gpu/drm/scheduler/sched_entity.c | 1 +
> > 
> > 
> > > 
> > > Signed-off-by: Lin.Cao <lincao12@amd.com>
> > 
> > This fixes a bug. Even a racy bug, it seems. So we need a Fixes tag
> > and
> > put the stable kernel in CC.
> > 
> > Please figure out with git blame, git log and git tag --contains
> > which
> > commit your patch fixes and which is the oldest kernel that
> > contains
> > the bug. Then add a Fixes: tag and Cc: the stable kernel. You'll
> > find
> > lots of examples for that in git log.
> > 
> > 
> > Thx
> > P.
> > 
> > > ---
> > >  drivers/gpu/drm/scheduler/sched_entity.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/drivers/gpu/drm/scheduler/sched_entity.c
> > > b/drivers/gpu/drm/scheduler/sched_entity.c
> > > index e671aa241720..66f2a43c58fd 100644
> > > --- a/drivers/gpu/drm/scheduler/sched_entity.c
> > > +++ b/drivers/gpu/drm/scheduler/sched_entity.c
> > > @@ -177,6 +177,7 @@ static void
> > > drm_sched_entity_kill_jobs_work(struct work_struct *wrk)
> > >  	struct drm_sched_job *job = container_of(wrk,
> > > typeof(*job), work);
> > >  
> > >  	drm_sched_fence_scheduled(job->s_fence, NULL);
> > > +	drm_sched_wakeup(job->sched);
> > >  	drm_sched_fence_finished(job->s_fence, -ESRCH);
> > >  	WARN_ON(job->s_fence->parent);
> > >  	job->sched->ops->free_job(job);
> > 
> 


  reply	other threads:[~2025-07-14 13:27 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-14  6:23 [PATCH v2] drm/scheduler: Fix sched hang when killing app with dependent jobs Lin.Cao
2025-07-14 11:03 ` Christian König
2025-07-14 12:46 ` Philipp Stanner
2025-07-14 13:08   ` Christian König
2025-07-14 13:27     ` Philipp Stanner [this message]
2025-07-14 13:39       ` Christian König
2025-07-15  3:38         ` cao, lin
2025-07-15  9:12           ` Philipp Stanner
2025-07-15  9:51             ` cao, lin
2025-07-15 10:27               ` Philipp Stanner
2025-07-15 10:52                 ` Christian König
2025-07-15 12:20                   ` Philipp Stanner
2025-07-15 12:32                     ` Christian König
2025-07-15 13:07                       ` Philipp Stanner
2025-07-15 13:20                         ` cao, lin

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=70d9c6a43846c3a3c266d4a7a431c1c4b3fcd05f.camel@mailbox.org \
    --to=phasta@mailbox.org \
    --cc=Emily.Deng@amd.com \
    --cc=christian.koenig@amd.com \
    --cc=dakr@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=lincao12@amd.com \
    --cc=matthew.brost@intel.com \
    --cc=phasta@kernel.org \
    --cc=zhenguo.yin@amd.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).