From: Philipp Stanner <phasta@kernel.org>
To: "Matthew Brost" <matthew.brost@intel.com>,
"Danilo Krummrich" <dakr@kernel.org>,
"Philipp Stanner" <phasta@kernel.org>,
"Christian König" <ckoenig.leichtzumerken@gmail.com>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Maxime Ripard" <mripard@kernel.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Sumit Semwal" <sumit.semwal@linaro.org>,
"Marco Pagani" <marco.pagani@linux.dev>,
"Tvrtko Ursulin" <tvrtko.ursulin@igalia.com>,
"Boris Brezillon" <boris.brezillon@collabora.com>
Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org
Subject: [PATCH 2/5] drm/sched: Lock spsc_queue in drm_sched_entity_pop_job()
Date: Wed, 1 Jul 2026 10:59:18 +0200 [thread overview]
Message-ID: <20260701085920.3253248-4-phasta@kernel.org> (raw)
In-Reply-To: <20260701085920.3253248-2-phasta@kernel.org>
Cleanup work in the preceding commit added locking to
drm_sched_entity_pop_job(). This cleanup causes a slightly sub-optimal
lock cycle with drm_sched_rq_pop_entity().
sched_entity also utilizes the lockless spsc_queue (partially already
used simultaneously with locks), which was marked for removal in
commit 6e7eb171ac96 ("Documentation: drm: Add entry for removing spsc_queue to TODO list")
To remove the lock-cycle mentioned above, the unlock must be moved
downwards, also locking the lockless queue.
Guard spsc_queue_pop() in drm_sched_entity_pop_job() with the lock and
document why that is being done.
Signed-off-by: Philipp Stanner <phasta@kernel.org>
---
drivers/gpu/drm/scheduler/sched_entity.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/scheduler/sched_entity.c b/drivers/gpu/drm/scheduler/sched_entity.c
index 91aec20611ad..5cf0af91faf2 100644
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -529,9 +529,17 @@ struct drm_sched_job *drm_sched_entity_pop_job(struct drm_sched_entity *entity)
spin_lock(&entity->lock);
prev_last_scheduled = entity->last_scheduled;
entity->last_scheduled = dma_fence_get(&sched_job->s_fence->finished);
- spin_unlock(&entity->lock);
+ /* Preceding cleanup work made it necessary to add the spinlock
+ * to this function. spsc_queue, a lockless queue, is now
+ * counterintuitively guarded by the lock as well. spsc_queue is queued
+ * for removal (see DRM TODO list), so this somewhat serves as a
+ * preparational step.
+ *
+ * TODO: Replace spsc_queue completely with a locked (h)list.
+ */
spsc_queue_pop(&entity->job_queue);
+ spin_unlock(&entity->lock);
dma_fence_put(prev_last_scheduled);
drm_sched_rq_pop_entity(entity);
--
2.54.0
next prev parent reply other threads:[~2026-07-01 8:59 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-01 8:59 [PATCH 0/5] drm/sched: Introduce the miracle of locking to entity Philipp Stanner
2026-07-01 8:59 ` [PATCH 1/5] drm/sched: Protect entity->last_scheduled with spinlock Philipp Stanner
2026-07-03 11:27 ` Tvrtko Ursulin
2026-07-03 14:47 ` Philipp Stanner
2026-07-06 8:45 ` Tvrtko Ursulin
2026-07-06 9:42 ` Philipp Stanner
2026-07-06 10:59 ` Tvrtko Ursulin
2026-07-06 14:37 ` Tvrtko Ursulin
2026-07-07 9:21 ` Tvrtko Ursulin
2026-07-01 8:59 ` Philipp Stanner [this message]
2026-07-01 8:59 ` [PATCH 3/5] drm/sched: Avoid lock cycle for sched_entity Philipp Stanner
2026-07-01 8:59 ` [PATCH 4/5] drm/sched: Lock drm_sched_entity_is_idle() Philipp Stanner
2026-07-01 9:47 ` Tvrtko Ursulin
2026-07-01 8:59 ` [PATCH 5/5] drm/sched: Remove entity->entity_idle Philipp Stanner
2026-07-01 9:09 ` sashiko-bot
2026-07-01 9:38 ` Philipp Stanner
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=20260701085920.3253248-4-phasta@kernel.org \
--to=phasta@kernel.org \
--cc=airlied@gmail.com \
--cc=boris.brezillon@collabora.com \
--cc=ckoenig.leichtzumerken@gmail.com \
--cc=dakr@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=marco.pagani@linux.dev \
--cc=matthew.brost@intel.com \
--cc=mripard@kernel.org \
--cc=simona@ffwll.ch \
--cc=sumit.semwal@linaro.org \
--cc=tvrtko.ursulin@igalia.com \
--cc=tzimmermann@suse.de \
/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.