From: "Danilo Krummrich" <dakr@kernel.org>
To: "Tvrtko Ursulin" <tvrtko.ursulin@igalia.com>
Cc: amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
kernel-dev@igalia.com,
"Christian König" <christian.koenig@amd.com>,
"Matthew Brost" <matthew.brost@intel.com>,
"Philipp Stanner" <phasta@kernel.org>,
"Pierre-Eric Pelloux-Prayer" <pierre-eric.pelloux-prayer@amd.com>
Subject: Re: [PATCH v5 09/28] drm/sched: Add fair scheduling policy
Date: Wed, 14 Jan 2026 23:13:11 +0100 [thread overview]
Message-ID: <DFONORJMB1ZM.1JHSIXB9ULHJV@kernel.org> (raw)
In-Reply-To: <20251219135351.25880-10-tvrtko.ursulin@igalia.com>
On Fri Dec 19, 2025 at 2:53 PM CET, Tvrtko Ursulin wrote:
> diff --git a/drivers/gpu/drm/scheduler/sched_rq.c b/drivers/gpu/drm/scheduler/sched_rq.c
> index 2d1f579d8352..2fde309d02a6 100644
> --- a/drivers/gpu/drm/scheduler/sched_rq.c
> +++ b/drivers/gpu/drm/scheduler/sched_rq.c
> @@ -16,6 +16,35 @@ drm_sched_entity_compare_before(struct rb_node *a, const struct rb_node *b)
> return ktime_before(ea->oldest_job_waiting, eb->oldest_job_waiting);
> }
>
> +static void drm_sched_rq_update_prio(struct drm_sched_rq *rq)
> +{
> + enum drm_sched_priority prio = DRM_SCHED_PRIORITY_INVALID;
> + struct rb_node *rb;
> +
> + lockdep_assert_held(&rq->lock);
> +
> + rb = rb_first_cached(&rq->rb_tree_root);
> + if (rb) {
> + struct drm_sched_entity *entity =
> + rb_entry(rb, typeof(*entity), rb_tree_node);
> +
> + /*
> + * The normal locking order is entity then run-queue so taking
> + * the entity lock here would be a locking inversion for the
> + * case when the current head of the run-queue is different from
> + * the one we already have locked. The unlocked read is fine
> + * though, because if the priority had just changed it is no big
> + * deal for our algorithm, but just a transient reachable only
> + * by drivers with userspace dynamic priority changes API. Equal
> + * in effect to the priority change becoming visible a few
> + * instructions later.
> + */
> + prio = READ_ONCE(entity->priority);
I still think that we should address the root cause of the lock inversion
problem instead.
I previously mentioned that I can take a look at this beginning of this year,
which I can do soon.
In the meantime, can you please explain what's the problem with this specific
case? This function is only ever called from drm_sched_rq_remove_fifo_locked()
and drm_sched_rq_update_fifo_locked(), which already seem to hold both locks.
> + }
> +
> + rq->head_prio = prio;
> +}
> +
> static void drm_sched_rq_remove_fifo_locked(struct drm_sched_entity *entity,
> struct drm_sched_rq *rq)
> {
> @@ -25,6 +54,7 @@ static void drm_sched_rq_remove_fifo_locked(struct drm_sched_entity *entity,
> if (!RB_EMPTY_NODE(&entity->rb_tree_node)) {
> rb_erase_cached(&entity->rb_tree_node, &rq->rb_tree_root);
> RB_CLEAR_NODE(&entity->rb_tree_node);
> + drm_sched_rq_update_prio(rq);
> }
> }
>
> @@ -46,6 +76,7 @@ static void drm_sched_rq_update_fifo_locked(struct drm_sched_entity *entity,
>
> rb_add_cached(&entity->rb_tree_node, &rq->rb_tree_root,
> drm_sched_entity_compare_before);
> + drm_sched_rq_update_prio(rq);
> }
next prev parent reply other threads:[~2026-01-14 22:13 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-19 13:53 [PATCH v5 00/28] Fair(er) DRM scheduler Tvrtko Ursulin
2025-12-19 13:53 ` [PATCH v5 01/28] drm/sched: Consolidate entity run queue management Tvrtko Ursulin
2025-12-19 13:53 ` [PATCH v5 02/28] drm/sched: Move run queue related code into a separate file Tvrtko Ursulin
2025-12-19 13:53 ` [PATCH v5 03/28] drm/sched: Add some scheduling quality unit tests Tvrtko Ursulin
2025-12-19 13:53 ` [PATCH v5 04/28] drm/sched: Add some more " Tvrtko Ursulin
2025-12-19 13:53 ` [PATCH v5 05/28] drm/sched: Implement RR via FIFO Tvrtko Ursulin
2025-12-19 13:53 ` [PATCH v5 06/28] drm/sched: Free all finished jobs at once Tvrtko Ursulin
2025-12-19 13:53 ` [PATCH v5 07/28] drm/sched: Account entity GPU time Tvrtko Ursulin
2026-01-14 17:48 ` Danilo Krummrich
2026-01-15 8:56 ` Tvrtko Ursulin
2026-01-15 12:06 ` Danilo Krummrich
2026-01-15 12:52 ` Tvrtko Ursulin
2026-01-15 13:18 ` Danilo Krummrich
2026-01-20 10:31 ` Tvrtko Ursulin
2025-12-19 13:53 ` [PATCH v5 08/28] drm/sched: Remove idle entity from tree Tvrtko Ursulin
2025-12-19 13:53 ` [PATCH v5 09/28] drm/sched: Add fair scheduling policy Tvrtko Ursulin
2026-01-14 22:13 ` Danilo Krummrich [this message]
2026-01-15 8:28 ` Tvrtko Ursulin
2026-01-15 11:44 ` Danilo Krummrich
2026-01-15 13:00 ` Tvrtko Ursulin
2026-01-15 23:39 ` Danilo Krummrich
2026-01-20 9:51 ` Tvrtko Ursulin
2026-03-07 1:17 ` Hillf Danton
2025-12-19 13:53 ` [PATCH v5 10/28] drm/sched: Favour interactive clients slightly Tvrtko Ursulin
2025-12-19 13:53 ` [PATCH v5 11/28] drm/sched: Switch default policy to fair Tvrtko Ursulin
2025-12-19 13:53 ` [PATCH v5 12/28] drm/sched: Remove FIFO and RR and simplify to a single run queue Tvrtko Ursulin
2025-12-19 13:53 ` [PATCH v5 13/28] drm/sched: Embed run queue singleton into the scheduler Tvrtko Ursulin
2025-12-19 13:53 ` [PATCH v5 14/28] accel/amdxdna: Remove drm_sched_init_args->num_rqs usage Tvrtko Ursulin
2025-12-19 13:53 ` [PATCH v5 15/28] accel/rocket: " Tvrtko Ursulin
2025-12-19 13:53 ` [PATCH v5 16/28] accel/ethosu: " Tvrtko Ursulin
2025-12-19 13:53 ` [PATCH v5 17/28] drm/amdgpu: " Tvrtko Ursulin
2025-12-19 13:53 ` [PATCH v5 18/28] drm/etnaviv: " Tvrtko Ursulin
2025-12-19 13:53 ` [PATCH v5 19/28] drm/imagination: " Tvrtko Ursulin
2025-12-19 13:53 ` [PATCH v5 20/28] drm/lima: " Tvrtko Ursulin
2025-12-19 13:53 ` [PATCH v5 21/28] drm/msm: " Tvrtko Ursulin
2025-12-19 13:53 ` [PATCH v5 22/28] drm/nouveau: " Tvrtko Ursulin
2025-12-19 13:53 ` [PATCH v5 23/28] drm/panfrost: " Tvrtko Ursulin
2025-12-19 13:53 ` [PATCH v5 24/28] drm/panthor: " Tvrtko Ursulin
2025-12-19 13:53 ` [PATCH v5 25/28] drm/sched: " Tvrtko Ursulin
2025-12-19 13:53 ` [PATCH v5 26/28] drm/v3d: " Tvrtko Ursulin
2025-12-19 13:53 ` [PATCH v5 27/28] drm/xe: " Tvrtko Ursulin
2025-12-19 13:53 ` [PATCH v5 28/28] drm/sched: Remove drm_sched_init_args->num_rqs 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=DFONORJMB1ZM.1JHSIXB9ULHJV@kernel.org \
--to=dakr@kernel.org \
--cc=amd-gfx@lists.freedesktop.org \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=kernel-dev@igalia.com \
--cc=matthew.brost@intel.com \
--cc=phasta@kernel.org \
--cc=pierre-eric.pelloux-prayer@amd.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox