Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>,
	DRI Development <dri-devel@lists.freedesktop.org>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	Melissa Wen <mwen@igalia.com>,
	Daniel Vetter <daniel.vetter@intel.com>,
	Steven Price <steven.price@arm.com>,
	Andrey Grodzovsky <andrey.grodzovsky@amd.com>,
	Lee Jones <lee.jones@linaro.org>,
	Boris Brezillon <boris.brezillon@collabora.com>
Subject: Re: [Intel-gfx] [PATCH v5 03/20] drm/sched: Barriers are needed for entity->last_scheduled
Date: Thu, 5 Aug 2021 15:45:13 +0200	[thread overview]
Message-ID: <2e3bd136-664d-f646-707c-ca1bfb6c0f16@amd.com> (raw)
In-Reply-To: <20210805104705.862416-4-daniel.vetter@ffwll.ch>



Am 05.08.21 um 12:46 schrieb Daniel Vetter:
> It might be good enough on x86 with just READ_ONCE, but the write side
> should then at least be WRITE_ONCE because x86 has total store order.
>
> It's definitely not enough on arm.
>
> Fix this proplery, which means
> - explain the need for the barrier in both places
> - point at the other side in each comment
>
> Also pull out the !sched_list case as the first check, so that the
> code flow is clearer.
>
> While at it sprinkle some comments around because it was very
> non-obvious to me what's actually going on here and why.
>
> Note that we really need full barriers here, at first I thought
> store-release and load-acquire on ->last_scheduled would be enough,
> but we actually requiring ordering between that and the queue state.
>
> v2: Put smp_rmp() in the right place and fix up comment (Andrey)
>
> Acked-by: Melissa Wen <mwen@igalia.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: "Christian König" <christian.koenig@amd.com>
> Cc: Steven Price <steven.price@arm.com>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: Boris Brezillon <boris.brezillon@collabora.com>

Reviewed-by: Christian König <christian.koenig@amd.com>

> ---
>   drivers/gpu/drm/scheduler/sched_entity.c | 27 ++++++++++++++++++++++--
>   1 file changed, 25 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/scheduler/sched_entity.c b/drivers/gpu/drm/scheduler/sched_entity.c
> index f7347c284886..89e3f6eaf519 100644
> --- a/drivers/gpu/drm/scheduler/sched_entity.c
> +++ b/drivers/gpu/drm/scheduler/sched_entity.c
> @@ -439,8 +439,16 @@ struct drm_sched_job *drm_sched_entity_pop_job(struct drm_sched_entity *entity)
>   		dma_fence_set_error(&sched_job->s_fence->finished, -ECANCELED);
>   
>   	dma_fence_put(entity->last_scheduled);
> +
>   	entity->last_scheduled = dma_fence_get(&sched_job->s_fence->finished);
>   
> +	/*
> +	 * If the queue is empty we allow drm_sched_entity_select_rq() to
> +	 * locklessly access ->last_scheduled. This only works if we set the
> +	 * pointer before we dequeue and if we a write barrier here.
> +	 */
> +	smp_wmb();
> +
>   	spsc_queue_pop(&entity->job_queue);
>   	return sched_job;
>   }
> @@ -459,10 +467,25 @@ void drm_sched_entity_select_rq(struct drm_sched_entity *entity)
>   	struct drm_gpu_scheduler *sched;
>   	struct drm_sched_rq *rq;
>   
> -	if (spsc_queue_count(&entity->job_queue) || !entity->sched_list)
> +	/* single possible engine and already selected */
> +	if (!entity->sched_list)
> +		return;
> +
> +	/* queue non-empty, stay on the same engine */
> +	if (spsc_queue_count(&entity->job_queue))
>   		return;
>   
> -	fence = READ_ONCE(entity->last_scheduled);
> +	/*
> +	 * Only when the queue is empty are we guaranteed that the scheduler
> +	 * thread cannot change ->last_scheduled. To enforce ordering we need
> +	 * a read barrier here. See drm_sched_entity_pop_job() for the other
> +	 * side.
> +	 */
> +	smp_rmb();
> +
> +	fence = entity->last_scheduled;
> +
> +	/* stay on the same engine if the previous job hasn't finished */
>   	if (fence && !dma_fence_is_signaled(fence))
>   		return;
>   


  reply	other threads:[~2021-08-05 13:45 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-05 10:46 [Intel-gfx] [PATCH v5 00/20] drm/sched dependency handling and implicit sync fixes Daniel Vetter
2021-08-05 10:46 ` [Intel-gfx] [PATCH v5 01/20] drm/sched: Split drm_sched_job_init Daniel Vetter
2021-08-05 13:43   ` Christian König
2021-08-05 14:07     ` Daniel Vetter
2021-08-05 14:47       ` Christian König
2021-08-05 15:07         ` Daniel Vetter
2021-08-17  8:49   ` [Intel-gfx] [PATCH] " Daniel Vetter
2021-08-05 10:46 ` [Intel-gfx] [PATCH v5 02/20] drm/msm: Fix drm/sched point of no return rules Daniel Vetter
2021-08-05 23:02   ` Rob Clark
2021-08-06 16:41     ` Daniel Vetter
2021-08-06 17:19       ` Rob Clark
2021-08-06 18:41         ` Daniel Vetter
2021-08-06 19:01           ` Rob Clark
2021-08-06 19:10             ` Daniel Vetter
2021-08-06 19:59               ` Rob Clark
2021-08-17  8:53   ` [Intel-gfx] [PATCH] drm/msm: Improve " Daniel Vetter
2021-08-26  9:33     ` Daniel Vetter
2021-08-26 15:38       ` Rob Clark
2021-08-05 10:46 ` [Intel-gfx] [PATCH v5 03/20] drm/sched: Barriers are needed for entity->last_scheduled Daniel Vetter
2021-08-05 13:45   ` Christian König [this message]
2021-08-05 10:46 ` [Intel-gfx] [PATCH v5 04/20] drm/sched: Add dependency tracking Daniel Vetter
2021-08-05 13:47   ` Christian König
2021-08-05 10:46 ` [Intel-gfx] [PATCH v5 05/20] drm/sched: drop entity parameter from drm_sched_push_job Daniel Vetter
2021-08-05 13:48   ` Christian König
2021-08-05 10:46 ` [Intel-gfx] [PATCH v5 06/20] drm/sched: improve docs around drm_sched_entity Daniel Vetter
2021-08-05 10:46 ` [Intel-gfx] [PATCH v5 07/20] drm/panfrost: use scheduler dependency tracking Daniel Vetter
2021-08-05 15:10   ` Alyssa Rosenzweig
2021-08-05 10:46 ` [Intel-gfx] [PATCH v5 08/20] drm/lima: " Daniel Vetter
2021-08-12 19:28   ` Daniel Vetter
2021-08-14  2:45     ` Qiang Yu
2021-08-05 10:46 ` [Intel-gfx] [PATCH v5 09/20] drm/v3d: Move drm_sched_job_init to v3d_job_init Daniel Vetter
2021-08-05 10:46 ` [Intel-gfx] [PATCH v5 10/20] drm/v3d: Use scheduler dependency handling Daniel Vetter
2021-08-05 10:46 ` [Intel-gfx] [PATCH v5 11/20] drm/etnaviv: " Daniel Vetter
2021-08-12 19:28   ` Daniel Vetter
2021-08-05 10:46 ` [Intel-gfx] [PATCH v5 12/20] drm/msm: " Daniel Vetter
2021-08-12 19:29   ` Daniel Vetter
2021-08-26 16:12   ` Rob Clark
2021-08-30  9:01   ` Daniel Vetter
2021-08-05 10:46 ` [Intel-gfx] [PATCH v5 13/20] drm/gem: Delete gem array fencing helpers Daniel Vetter
2021-08-12 19:29   ` Daniel Vetter
2021-08-05 10:46 ` [Intel-gfx] [PATCH v5 14/20] drm/sched: Don't store self-dependencies Daniel Vetter
2021-08-05 13:18   ` Christian König
2021-08-05 13:25     ` Daniel Vetter
2021-08-05 13:57       ` Christian König
2021-08-05 15:06         ` Daniel Vetter
2021-08-05 10:47 ` [Intel-gfx] [PATCH v5 15/20] drm/sched: Check locking in drm_sched_job_await_implicit Daniel Vetter
2021-08-05 13:19   ` Christian König
2021-08-05 13:27     ` Daniel Vetter
2021-08-05 10:47 ` [Intel-gfx] [PATCH v5 16/20] drm/msm: Don't break exclusive fence ordering Daniel Vetter
2021-08-26 16:16   ` Rob Clark
2021-08-30  9:02     ` Daniel Vetter
2021-08-05 10:47 ` [Intel-gfx] [PATCH v5 17/20] drm/etnaviv: " Daniel Vetter
2021-08-05 10:47 ` [Intel-gfx] [PATCH v5 18/20] drm/i915: delete exclude argument from i915_sw_fence_await_reservation Daniel Vetter
2021-08-05 10:47 ` [Intel-gfx] [PATCH v5 19/20] drm/i915: Don't break exclusive fence ordering Daniel Vetter
2021-08-05 10:47 ` [Intel-gfx] [PATCH v5 20/20] dma-resv: Give the docs a do-over Daniel Vetter
2021-08-30 19:38   ` Daniel Vetter
2021-08-05 13:58 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/sched dependency handling and implicit sync fixes Patchwork
2021-08-05 14:29 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2021-08-06 19:14 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/sched dependency handling and implicit sync fixes (rev2) Patchwork
2021-08-17 16:27 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/sched dependency handling and implicit sync fixes (rev4) Patchwork
2021-08-17 16:57 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-08-17 18:15 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2021-08-26 13:17 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/sched dependency handling and implicit sync fixes (rev5) Patchwork
2021-08-26 13:48 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-08-26 21:46 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork

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=2e3bd136-664d-f646-707c-ca1bfb6c0f16@amd.com \
    --to=christian.koenig@amd.com \
    --cc=andrey.grodzovsky@amd.com \
    --cc=boris.brezillon@collabora.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=lee.jones@linaro.org \
    --cc=mwen@igalia.com \
    --cc=steven.price@arm.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