All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>,
	amd-gfx@lists.freedesktop.org, "Zhang,
	Hawking" <Hawking.Zhang@amd.com>
Cc: kernel-dev@igalia.com, Danilo Krummrich <dakr@kernel.org>,
	Matthew Brost <matthew.brost@intel.com>,
	Philipp Stanner <phasta@kernel.org>
Subject: Re: [PATCH 1/4] drm/scheduler: Add drm_sched_cancel_all_jobs helper
Date: Wed, 5 Feb 2025 16:42:05 +0100	[thread overview]
Message-ID: <44edde63-7181-44fb-a4f7-94e50514f539@amd.com> (raw)
In-Reply-To: <20250205153332.14852-2-tvrtko.ursulin@igalia.com>

Adding Hawking for commenting on RAS.

Am 05.02.25 um 16:33 schrieb Tvrtko Ursulin:
> The helper copies code from the existing amdgpu_job_stop_all_jobs_on_sched
> with the purpose of reducing the amount of driver code which directly
> touch scheduler internals.
>
> If or when amdgpu manages to change the approach for handling the
> permanently wedged state this helper can be removed.

When RAS indicates a problem and reset is disabled we shouldn't mess 
with the scheduler internals, but rather mark the device as unplugged 
and clear the PCIe DMA bits.

In other words enter the wedged state which is now well documented.

This way all submissions will run into ENODEV errors and be cleaned up 
immediately on submission by the scheduler. Applications will then just 
wait for their existing submissions and get an error if they try to send 
new ones.

Stopping the scheduler and then messing with the internals is basically 
just a really ugly hack. and never made sense in the first place as far 
as I can see.

See below for more comments.

>
> 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>
> Cc: Philipp Stanner <phasta@kernel.org>
> ---
>   drivers/gpu/drm/scheduler/sched_main.c | 44 ++++++++++++++++++++++++++
>   include/drm/gpu_scheduler.h            |  1 +
>   2 files changed, 45 insertions(+)
>
> diff --git a/drivers/gpu/drm/scheduler/sched_main.c b/drivers/gpu/drm/scheduler/sched_main.c
> index a48be16ab84f..0363655db22d 100644
> --- a/drivers/gpu/drm/scheduler/sched_main.c
> +++ b/drivers/gpu/drm/scheduler/sched_main.c
> @@ -703,6 +703,50 @@ void drm_sched_start(struct drm_gpu_scheduler *sched, int errno)
>   }
>   EXPORT_SYMBOL(drm_sched_start);
>   
> +/**
> + * drm_sched_cancel_all_jobs - Cancel all queued and scheduled jobs
> + *
> + * @sched: scheduler instance
> + * @errno: error value to set on signaled fences
> + *
> + * Signal all queued and scheduled jobs and set them to error state.
> + *
> + * Scheduler must be stopped before calling this.
> + */
> +void drm_sched_cancel_all_jobs(struct drm_gpu_scheduler *sched, int errno)
> +{
> +	struct drm_sched_entity *entity;
> +	struct drm_sched_fence *s_fence;
> +	struct drm_sched_job *job;
> +	enum drm_sched_priority p;
> +
> +	drm_WARN_ON_ONCE(sched, !sched->pause_submit);
> +
> +	/* Signal all jobs not yet scheduled */
> +	for (p = DRM_SCHED_PRIORITY_KERNEL; p < sched->num_rqs; p++) {
> +		struct drm_sched_rq *rq = sched->sched_rq[p];
> +
> +		spin_lock(&rq->lock);
> +		list_for_each_entry(entity, &rq->entities, list) {
> +			while ((job = to_drm_sched_job(spsc_queue_pop(&entity->job_queue)))) {
> +				s_fence = job->s_fence;
> +				dma_fence_signal(&s_fence->scheduled);
> +				dma_fence_set_error(&s_fence->finished, errno);
> +				dma_fence_signal(&s_fence->finished);
> +			}
> +		}
> +		spin_unlock(&rq->lock);
> +	}
> +
> +	/* Signal all jobs already scheduled to HW */
> +	list_for_each_entry(job, &sched->pending_list, list) {
> +		s_fence = job->s_fence;
> +		dma_fence_set_error(&s_fence->finished, errno);
> +		dma_fence_signal(&s_fence->finished);
> +	}

This is in the wrong order, e.g. already scheduled jobs need to signal 
first and then not yet scheduled ones. Otherwise you violate the 
dma_fence ordering rules.

Additional to that this is racy like hell, e.g. even when we had an RAS 
error it is perfectly possible that submissions finish normally.

Regards,
Christian.

> +}
> +EXPORT_SYMBOL(drm_sched_cancel_all_jobs);
> +
>   /**
>    * drm_sched_resubmit_jobs - Deprecated, don't use in new code!
>    *
> diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
> index a0ff08123f07..298513f8c327 100644
> --- a/include/drm/gpu_scheduler.h
> +++ b/include/drm/gpu_scheduler.h
> @@ -579,6 +579,7 @@ void drm_sched_wqueue_stop(struct drm_gpu_scheduler *sched);
>   void drm_sched_wqueue_start(struct drm_gpu_scheduler *sched);
>   void drm_sched_stop(struct drm_gpu_scheduler *sched, struct drm_sched_job *bad);
>   void drm_sched_start(struct drm_gpu_scheduler *sched, int errno);
> +void drm_sched_cancel_all_jobs(struct drm_gpu_scheduler *sched, int errno);
>   void drm_sched_resubmit_jobs(struct drm_gpu_scheduler *sched);
>   void drm_sched_increase_karma(struct drm_sched_job *bad);
>   void drm_sched_reset_karma(struct drm_sched_job *bad);


  reply	other threads:[~2025-02-05 15:50 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-05 15:33 [PATCH v2 0/4] Decouple amdgpu from the scheduler, a bit Tvrtko Ursulin
2025-02-05 15:33 ` [PATCH 1/4] drm/scheduler: Add drm_sched_cancel_all_jobs helper Tvrtko Ursulin
2025-02-05 15:42   ` Christian König [this message]
2025-02-06 13:35   ` Philipp Stanner
2025-02-06 13:42     ` Tvrtko Ursulin
2025-02-06 13:46     ` Christian König
2025-02-06 13:53       ` Tvrtko Ursulin
2025-02-06 14:00         ` Philipp Stanner
2025-02-06 14:01         ` Christian König
2025-02-06 13:53       ` Philipp Stanner
2025-02-06 14:25       ` Danilo Krummrich
2025-02-06 15:04       ` Zhang, Hawking
2025-02-05 15:33 ` [PATCH 2/4] drm/amdgpu: Use " Tvrtko Ursulin
2025-02-05 15:33 ` [PATCH 3/4] drm/sched: Add internal job peek/pop API Tvrtko Ursulin
2025-02-06 13:39   ` Philipp Stanner
2025-02-05 15:33 ` [PATCH 4/4] drm/sched: Make the type of drm_sched_job->last_dependency consistent 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=44edde63-7181-44fb-a4f7-94e50514f539@amd.com \
    --to=christian.koenig@amd.com \
    --cc=Hawking.Zhang@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=dakr@kernel.org \
    --cc=kernel-dev@igalia.com \
    --cc=matthew.brost@intel.com \
    --cc=phasta@kernel.org \
    --cc=tvrtko.ursulin@igalia.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 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.