Changes since v2:
  - Fix ordering bug between spsc_queue_pop() and
    drm_sched_rq_pop_entity().

Changes since v1:
  - Remove a bunch of patches; make this series only about locking
    entity->last_scheduled. The rest shall be done in separate patches
    and series. Consequently, also do not lock spsc_queue, yet.
  - Move lock-cycle patch to first position. (Tvrtko)


Both Tvrtko [1] and I [2] have recently proposed some improvals for
drm_sched.

While taking Tvrtko's feedback into account for my patch, I realized
that both his and my patch can be fully replaced with a bigger and far
more beautiful series.

If I am not mistaken, it turns out that the entire entity->entity_idle
completion is also nothing but a workaround around the grave mistake of
not using the greatest helper with parallel programming that exists in
computer science: Locking.

This series adds locking to the last_scheduled field and all checks
related to detect the idleness of the entity. As before, the
job_scheduled event queue causes the periodic checks.

This way, we can get rid of memory barriers, RCU, a few lines of code,
make things more readable, understandable...

Greetings,
Philipp

[1] https://lore.kernel.org/dri-devel/20260611123423.39819-1-tvrtko.ursulin@igalia.com/
[2] https://lore.kernel.org/dri-devel/20260626081942.2122144-2-phasta@kernel.org/

Philipp Stanner (3):
  drm/sched: Lock drm_sched_rq_pop_entity() externally
  drm/sched: Lock spsc_queue_pop() in drm_sched_entity_pop_job()
  drm/sched: Protect entity->last_scheduled with spinlock

 drivers/gpu/drm/scheduler/sched_entity.c | 53 ++++++++++--------------
 drivers/gpu/drm/scheduler/sched_rq.c     |  4 +-
 include/drm/gpu_scheduler.h              | 10 ++---
 3 files changed, 28 insertions(+), 39 deletions(-)

-- 
2.55.0

On 10/09/2026 08:59, Philipp Stanner wrote:
> Changes since v2:
>    - Fix ordering bug between spsc_queue_pop() and
>      drm_sched_rq_pop_entity().
> 
> Changes since v1:
>    - Remove a bunch of patches; make this series only about locking
>      entity->last_scheduled. The rest shall be done in separate patches
>      and series. Consequently, also do not lock spsc_queue, yet.
>    - Move lock-cycle patch to first position. (Tvrtko)
> 
> 
> Both Tvrtko [1] and I [2] have recently proposed some improvals for
> drm_sched.
> 
> While taking Tvrtko's feedback into account for my patch, I realized
> that both his and my patch can be fully replaced with a bigger and far
> more beautiful series.
> 
> If I am not mistaken, it turns out that the entire entity->entity_idle
> completion is also nothing but a workaround around the grave mistake of
> not using the greatest helper with parallel programming that exists in
> computer science: Locking.
> 
> This series adds locking to the last_scheduled field and all checks
> related to detect the idleness of the entity. As before, the
> job_scheduled event queue causes the periodic checks.
> 
> This way, we can get rid of memory barriers, RCU, a few lines of code,
> make things more readable, understandable...
> 
> Greetings,
> Philipp
> 
> [1] https://lore.kernel.org/dri-devel/20260611123423.39819-1-tvrtko.ursulin@igalia.com/
> [2] https://lore.kernel.org/dri-devel/20260626081942.2122144-2-phasta@kernel.org/
> 
> Philipp Stanner (3):
>    drm/sched: Lock drm_sched_rq_pop_entity() externally
>    drm/sched: Lock spsc_queue_pop() in drm_sched_entity_pop_job()

FWIW if you could review 
https://lore.kernel.org/dri-devel/20260907130527.52530-1-tvrtko.ursulin@igalia.com/ 
you could drop the first two patches from your series. Extra benefit is 
that patch fixes a bug and has been tested by the user.

Regards,

Tvrtko

>    drm/sched: Protect entity->last_scheduled with spinlock
> 
>   drivers/gpu/drm/scheduler/sched_entity.c | 53 ++++++++++--------------
>   drivers/gpu/drm/scheduler/sched_rq.c     |  4 +-
>   include/drm/gpu_scheduler.h              | 10 ++---
>   3 files changed, 28 insertions(+), 39 deletions(-)
>

On Fri, 2026-09-11 at 09:19 +0100, Tvrtko Ursulin wrote:
> FWIW if you could review 
> https://lore.kernel.org/dri-devel/20260907130527.52530-1-tvrtko.ursulin@igalia.com/ 
> you could drop the first two patches from your series. Extra benefit is 
> that patch fixes a bug and has been tested by the user.

See the other thread; I'm not super-hard opposed, but if we can agree
on getting CFS to a non-experimental status by first improving
spsc_queue, then it would be nicer from the diff / git log perspective
to have these little patches as a preparational base-line for the spsc
rework :)

Greetings
Philipp