kernel/linux.git/include/drm/gpu_scheduler.h, branch v7.2-rc1

drm/sched: Remove drm_sched_init_args->num_rqs

2026-04-17T12:43:30+00:00

Remove member no longer used by the scheduler core and the drivers. Signed-off-by: Tvrtko Ursulin Cc: Christian König Cc: Danilo Krummrich Cc: Matthew Brost Cc: Philipp Stanner Acked-by: Danilo Krummrich Tested-by: Vitaly Prosyak Signed-off-by: Philipp Stanner Link: https://patch.msgid.link/20260417103744.76020-30-tvrtko.ursulin@igalia.com

drm/sched: Embed run queue singleton into the scheduler

2026-04-17T12:43:29+00:00

Now that the run queue to scheduler relationship is always 1:1 we can embed it (the run queue) directly in the scheduler struct and save on some allocation error handling code and such. Signed-off-by: Tvrtko Ursulin Cc: Christian König Cc: Danilo Krummrich Cc: Matthew Brost Cc: Philipp Stanner Acked-by: Danilo Krummrich Tested-by: Vitaly Prosyak Signed-off-by: Philipp Stanner Link: https://patch.msgid.link/20260417103744.76020-15-tvrtko.ursulin@igalia.com

drm/sched: Remove FIFO and RR and simplify to a single run queue

2026-04-17T12:43:29+00:00

Since the new FAIR policy is in general better than FIFO and almost as good as round-robin in interactive use cases, plus the latter has not been the default policy in a long time, we can afford to remove both and leave just FAIR. By doing so we can simplify the scheduler code by making the scheduler to run queue relationship always 1:1 and remove some code. Also, now that the FIFO policy is gone the tree of entities is not a FIFO tree any more so rename it to just the tree. Signed-off-by: Tvrtko Ursulin Cc: Christian König Cc: Danilo Krummrich Cc: Matthew Brost Cc: Philipp Stanner Acked-by: Danilo Krummrich Tested-by: Vitaly Prosyak Signed-off-by: Philipp Stanner Link: https://patch.msgid.link/20260417103744.76020-14-tvrtko.ursulin@igalia.com

drm/sched: Favour interactive clients slightly

2026-04-17T12:43:28+00:00

GPUs do not always implement preemption and DRM scheduler definitely does not support it at the front end scheduling level. This means execution quanta can be quite long and is controlled by userspace, consequence of which is picking the "wrong" entity to run can have a larger negative effect than it would have with a virtual runtime based CPU scheduler. Another important consideration is that rendering clients often have shallow submission queues, meaning they will be entering and exiting the scheduler's runnable queue often. Relevant scenario here is what happens when an entity re-joins the runnable queue with other entities already present. One cornerstone of the virtual runtime algorithm is to let it re-join at the head and rely on the virtual runtime accounting and timeslicing to sort it out. However, as explained above, this may not work perfectly in the GPU world. Entity could always get to overtake the existing entities, or not, depending on the submission order and rbtree equal key insertion behaviour. Allow interactive jobs to overtake entities already queued up for the limited case when interactive entity is re-joining the queue after being idle. This gives more opportunity for the compositors to have their rendering executed before the GPU hogs even if they have been configured with the same scheduling priority. To classify a client as interactive we look at its average job duration versus the average for the whole scheduler. We can track this easily by plugging into the existing job runtime tracking and applying the exponential moving average window on the past submissions. Then, all other things being equal, we let the more interactive jobs go first. Signed-off-by: Tvrtko Ursulin Cc: Christian König Cc: Danilo Krummrich Cc: Matthew Brost Cc: Philipp Stanner Cc: Pierre-Eric Pelloux-Prayer Acked-by: Danilo Krummrich Tested-by: Vitaly Prosyak Signed-off-by: Philipp Stanner Link: https://patch.msgid.link/20260417103744.76020-12-tvrtko.ursulin@igalia.com

drm/sched: Add fair scheduling policy

2026-04-17T12:43:28+00:00

The FAIR scheduling policy is built upon the same concepts as the well known CFS CPU scheduler - entity run queue is sorted by the virtual GPU time consumed by entities in a way that the entity with least vruntime runs first. It is able to avoid total priority starvation, which is one of the problems with FIFO, and it also does not need for per priority run queues. As it scales the actual GPU runtime by an exponential factor as the priority decreases, the virtual runtime for low priority entities grows faster than for normal priority, pushing them further down the runqueue order for the same real GPU time spent. Apart from this fundamental fairness, fair policy is especially strong in oversubscription workloads where it is able to give more GPU time to short and bursty workloads when they are running in parallel with GPU heavy clients submitting deep job queues. Signed-off-by: Tvrtko Ursulin Cc: Christian König Cc: Danilo Krummrich Cc: Matthew Brost Cc: Philipp Stanner Cc: Pierre-Eric Pelloux-Prayer Acked-by: Danilo Krummrich Tested-by: Vitaly Prosyak Signed-off-by: Philipp Stanner Link: https://patch.msgid.link/20260417103744.76020-11-tvrtko.ursulin@igalia.com

drm/sched: Account entity GPU time

2026-04-17T12:43:28+00:00

To implement fair scheduling we need a view into the GPU time consumed by entities. Problem we have is that jobs and entities objects have decoupled lifetimes, where at the point we have a view into accurate GPU time, we cannot link back to the entity any longer. Solve this by adding a light weight entity stats object which is reference counted by both entity and the job and hence can safely be used from either side. With that, the only other thing we need is to add a helper for adding the job's GPU time into the respective entity stats object, and call it once the accurate GPU time has been calculated. The most convenient place to do that is the free job worker for several reasons. Doing the accounting from the job completion callback would mean a few locks would need to become irq safe and we would also need to worry about out of order completions (via dma_fence_is_signaled calls which we cannot control). In-order completions are critical for GPU time accuracy which is currently adjusted per fence in the free worker and requires looking at the next job in the scheduler pending list. We would also need to add a new lock to protect the scheduler average stats update. In contrast to those complications, having the accounting done from the free worker is serialized by definition and all the above complications are avoided. Downside is there is potential for a time lag between job completions and GPU time being accounted against the entity. Since that is partly alleviated by batch processing the completed job queue, and the scheduling algorithm does not attempt to be completely fair, which would even be rather impossible to achieve in the GPU world with the current DRM scheduler design and hardware with no or poor preemption support, this downside is not considered critical. Plus, in practice the scheduler is also affected by worker scheduling delays from other angles too. Not least being able to promptly feed the GPU with new work. We therefore choose the simple option and can later consider improving upon it if the need arises. Signed-off-by: Tvrtko Ursulin Cc: Christian König Cc: Danilo Krummrich Cc: Matthew Brost Cc: Philipp Stanner Acked-by: Danilo Krummrich Tested-by: Vitaly Prosyak Signed-off-by: Philipp Stanner Link: https://patch.msgid.link/20260417103744.76020-9-tvrtko.ursulin@igalia.com

drm/sched: Implement RR via FIFO

2026-04-17T12:43:28+00:00

Round-robin being the non-default policy and unclear how much it is used, we can notice that it can be implemented using the FIFO data structures if we only invent a fake submit timestamp which is monotonically increasing inside drm_sched_rq instances. So instead of remembering which was the last entity the scheduler worker picked we can simply bump the picked one to the bottom of the tree, which ensures round-robin behaviour between all active queued jobs. If the picked job was the last from a given entity, we remember the assigned fake timestamp and use it to re-insert the job once it re-joins the queue. This ensures the job neither overtakes all already queued jobs, neither it goes last. Instead it keeps the position after the currently queued jobs and before the ones which haven't yet been queued at the point the entity left the queue. Advantage is that we can consolidate to a single code path and remove a bunch of code. Downside is round-robin mode now needs to lock on the job pop path but that should not have a measurable performance impact. Signed-off-by: Tvrtko Ursulin Cc: Christian König Cc: Danilo Krummrich Cc: Matthew Brost Cc: Philipp Stanner Acked-by: Danilo Krummrich Tested-by: Vitaly Prosyak Signed-off-by: Philipp Stanner Link: https://patch.msgid.link/20260417103744.76020-7-tvrtko.ursulin@igalia.com

drm/sched: Make drm_sched_entity_kill() a public function

2026-04-16T19:34:00+00:00

Some drivers do not care on teardown whether the last jobs pending in an entity are actually executed before teardown completed. For such scenarios, drm_sched_entity_flush() is not the ideal function since it's intended to wait for jobs to complete. Make drm_sched_entity_kill() public for that use-case and update the documentation. Suggested-by: Danilo Krummrich Signed-off-by: Philipp Stanner Link: https://patch.msgid.link/20260415144956.272506-2-phasta@kernel.org Signed-off-by: Danilo Krummrich

drm/sched: Add pending job list iterator

2025-12-13T08:34:21+00:00

Stop open coding pending job list in drivers. Add pending job list iterator which safely walks DRM scheduler list asserting DRM scheduler is stopped. Signed-off-by: Matthew Brost Reviewed-by: Niranjana Vishwanathapura Link: https://patch.msgid.link/20251209200039.1366764-3-matthew.brost@intel.com

drm/sched: Add several job helpers to avoid drivers touching scheduler state

2025-12-13T08:34:20+00:00

In the past, drivers used to reach into scheduler internals—this must end because it makes it difficult to change scheduler internals, as driver-side code must also be updated. Add helpers to check if the scheduler is stopped and to query a job’s signaled state to avoid reaching into scheduler internals. These are expected to be used driver-side in recovery and debug flows. Signed-off-by: Matthew Brost Reviewed-by: Niranjana Vishwanathapura Link: https://patch.msgid.link/20251209200039.1366764-2-matthew.brost@intel.com