kernel/linux.git/drivers/gpu/drm/scheduler, branch v7.2-rc1

drm/sched: Fix clang build warning in kunit tests

2026-05-29T09:37:12+00:00

Initializing compile time constant struct or arrays from another such variable is a gcc extension, while clang strictly requires a compile time constant literal. As reported by LKP: >> drivers/gpu/drm/scheduler/tests/tests_scheduler.c:675:10: error: initializer element is not a compile-time constant drm_sched_scheduler_two_clients_attr), ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ include/kunit/test.h:224:13: note: expanded from macro 'KUNIT_CASE_PARAM_ATTR' .attr = attributes, .module_name = KBUILD_MODNAME} ^~~~~~~~~~ 1 error generated. vim +675 drivers/gpu/drm/scheduler/tests/tests_scheduler.c 671 672 static struct kunit_case drm_sched_scheduler_two_clients_tests[] = { 673 KUNIT_CASE_PARAM_ATTR(drm_sched_scheduler_two_clients_test, 674 drm_sched_scheduler_two_clients_gen_params, > 675 drm_sched_scheduler_two_clients_attr), 676 {} 677 }; 678 Fix it by using a compound literal as other tests do. Signed-off-by: Tvrtko Ursulin Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202605220312.Pu7UO05u-lkp@intel.com/ Fixes: 97ef806a5314 ("drm/sched: Add some scheduling quality unit tests") Cc: Philipp Stanner Acked-by: Philipp Stanner Signed-off-by: Tvrtko Ursulin Link: https://lore.kernel.org/r/20260522090129.9385-1-tvrtko.ursulin@igalia.com

drm/sched: Remove drm_sched_init_args->num_rqs usage

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

Remove member no longer used by the scheduler core. Signed-off-by: Tvrtko Ursulin Cc: Matthew Brost Cc: Danilo Krummrich Cc: Philipp Stanner Cc: Christian König Cc: dri-devel@lists.freedesktop.org Reviewed-by: Matthew Brost Signed-off-by: Philipp Stanner Link: https://patch.msgid.link/20260417103744.76020-27-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: Switch default policy to fair

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

FAIR policy works better than FIFO for all known use cases and either matches or gets close to RR. Lets make it a default to improve the user experience especially with interactive workloads competing with heavy clients. 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-13-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: Remove idle entity from tree

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

There is no need to keep entities with no jobs in the tree so lets remove it once the last job is consumed. This keeps the tree smaller which is nicer and more efficient as entities are removed and re-added on every popped job. Apart from that, the upcoming fair scheduling algorithm will rely on the tree only containing runnable entities. 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-10-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: Free all finished jobs at once

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

To implement fair scheduling we will need as accurate as possible view into per entity GPU time utilisation. Because sched fence execution time are only adjusted for accuracy in the free worker we need to process completed jobs as soon as possible so the metric is most up to date when view from the submission side of things. Signed-off-by: Tvrtko Ursulin Cc: Christian König Cc: Danilo Krummrich Cc: Matthew Brost Cc: Philipp Stanner Reviewed-by: Matthew Brost Acked-by: Danilo Krummrich Tested-by: Vitaly Prosyak Signed-off-by: Philipp Stanner Link: https://patch.msgid.link/20260417103744.76020-8-tvrtko.ursulin@igalia.com