linux-stable.git/drivers/gpu/drm/scheduler/tests, branch master

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: Add some more scheduling quality unit tests

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

This time round we explore the rate of submitted job queue processing
with multiple identical parallel clients.

Example test output:

3 clients:
        t               cycle:     min  avg max : ...
        +     0ms                   0    0    0 :   0   0   0
        +   102ms                   2    2    2 :   2   2   2
        +   208ms                   5    6    6 :   6   5   5
        +   310ms                   8    9    9 :   9   9   8
...
        +  2616ms                  82   83   83 :  83  83  82
        +  2717ms                  83   83   83 :  83  83  83
    avg_max_min_delta(x100)=60

Every 100ms for the duration of the test it logs how many jobs each
client had completed, prefixed by minimum, average and maximum numbers.
When finished overall average delta between max and min is output as a
rough indicator to scheduling fairness.

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: Christian König 
Acked-by: Danilo Krummrich 
Tested-by: Vitaly Prosyak 
Signed-off-by: Philipp Stanner 
Link: https://patch.msgid.link/20260417103744.76020-6-tvrtko.ursulin@igalia.com

drm/sched: Add some scheduling quality unit tests

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

To make evaluating different scheduling policies easier (no need for
external benchmarks) and perfectly repeatable, lets add some synthetic
workloads built upon mock scheduler unit test infrastructure.

Focus is on two parallel clients (two threads) submitting different job
patterns and logging their progress and some overall metrics. This is
repeated for both scheduler credit limit 1 and 2.

Example test output:

  Normal and low:
                    pct1 cps1 qd1;  pct2 cps2 qd2
        +     0ms:   0     0    0;   0     0    0
        +   104ms: 100  1240  112; 100  1240  125
        +   209ms: 100     0   99; 100     0  125
        +   313ms: 100     0   86; 100     0  125
        +   419ms: 100     0   73; 100     0  125
        +   524ms: 100     0   60; 100     0  125
        +   628ms: 100     0   47; 100     0  125
        +   731ms: 100     0   34; 100     0  125
        +   836ms: 100     0   21; 100     0  125
        +   939ms: 100     0    8; 100     0  125
        +  1043ms:               ; 100     0  120
        +  1147ms:               ; 100     0  107
        +  1252ms:               ; 100     0   94
        +  1355ms:               ; 100     0   81
        +  1459ms:               ; 100     0   68
        +  1563ms:               ; 100     0   55
        +  1667ms:               ; 100     0   42
        +  1771ms:               ; 100     0   29
        +  1875ms:               ; 100     0   16
        +  1979ms:               ; 100     0    3
    0: prio=normal sync=0 elapsed_ms=1015ms (ideal_ms=1000ms) cycle_time(min,avg,max)=134,222,978 us latency_time(min,avg,max)=134,222,978
us
    1: prio=low sync=0 elapsed_ms=2009ms (ideal_ms=1000ms) cycle_time(min,avg,max)=134,215,806 us latency_time(min,avg,max)=134,215,806 us

There we have two clients represented in the two respective columns, with
their progress logged roughly every 100 milliseconds. The metrics are:

 - pct - Percentage progress of the job submit part
 - cps - Cycles per second
 - qd  - Queue depth - number of submitted unfinished jobs

The cycles per second metric is inherent to the fact that workload
patterns are a data driven cycling sequence of:

 - Submit 1..N jobs
 - Wait for Nth job to finish (optional)
 - Sleep (optional)
 - Repeat from start

In this particular example we have a normal priority and a low priority
client both spamming the scheduler with 8ms jobs with no sync and no
sleeping. Hence they build very deep queues and we can see how the low
priority client is completely starved until the normal finishes.

Note that the PCT and CPS metrics are irrelevant for "unsync" clients
since they manage to complete all of their cycles instantaneously.

A different example would be:

  Heavy and interactive:
                    pct1 cps1 qd1;  pct2 cps2 qd2
        +     0ms:   0     0    0;   0     0    0
        +   106ms:   5    40    3;   5    40    0
        +   209ms:   9    40    0;   9    40    0
        +   314ms:  14    50    3;  14    50    0
        +   417ms:  18    40    0;  18    40    0
        +   522ms:  23    50    3;  23    50    0
        +   625ms:  27    40    0;  27    40    1
        +   729ms:  32    50    0;  32    50    0
        +   833ms:  36    40    1;  36    40    0
        +   937ms:  40    40    0;  40    40    0
        +  1041ms:  45    50    0;  45    50    0
        +  1146ms:  49    40    1;  49    40    1
        +  1249ms:  54    50    0;  54    50    0
        +  1353ms:  58    40    1;  58    40    0
        +  1457ms:  62    40    0;  62    40    1
        +  1561ms:  67    50    0;  67    50    0
        +  1665ms:  71    40    1;  71    40    0
        +  1772ms:  76    50    0;  76    50    0
        +  1877ms:  80    40    1;  80    40    0
        +  1981ms:  84    40    0;  84    40    0
        +  2085ms:  89    50    0;  89    50    0
        +  2189ms:  93    40    1;  93    40    0
        +  2293ms:  97    40    0;  97    40    1

In this case client one is submitting 3x 2.5ms jobs, waiting for the 3rd
and then sleeping for 2.5ms (in effect causing 75% GPU load, minus the
overheads). Second client is submitting 1ms jobs, waiting for each to
finish and sleeping for 9ms (effective 10% GPU load). Here we can see
the PCT and CPS reflecting real progress.

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: Christian König 
Acked-by: Danilo Krummrich 
Tested-by: Vitaly Prosyak 
Signed-off-by: Philipp Stanner 
Link: https://patch.msgid.link/20260417103744.76020-5-tvrtko.ursulin@igalia.com

drm/tests: Mark slow tests as slow

2026-02-27T09:39:34+00:00

Some DRM tests cross the 1s execution time threshold that defines a test
as slow. Let's flag them as such.

Reviewed-by: Arunpravin Paneer Selvam 
Reviewed-by: Tvrtko Ursulin 
Reviewed-by: Thomas Zimmermann 
Link: https://patch.msgid.link/20260224110310.1854608-1-mripard@kernel.org
Signed-off-by: Maxime Ripard

drm/sched/tests: Remove relict of done_list

2025-09-19T12:10:34+00:00

A rework of the scheduler unit tests removed the done_list. That list is
still mentioned in the mock test header.

Remove that relict.

Fixes: 4576de9b7977 ("drm/sched/tests: Implement cancel_job() callback")
Reviewed-by: Tvrtko Ursulin 
Signed-off-by: Philipp Stanner 
Link: https://lore.kernel.org/r/20250919064450.147176-2-phasta@kernel.org

drm/sched/tests: Remove redundant header files

2025-08-28T08:13:56+00:00

The header file  is already included on line 8. Remove the
redundant include.

Fixes: 5a99350794fec ("drm/sched: Add scheduler unit testing infrastructure and some basic tests")
Signed-off-by: Liao Yuanhong 
Reviewed-by: Tvrtko Ursulin 
Signed-off-by: Philipp Stanner 
Link: https://lore.kernel.org/r/20250819142630.368796-1-liaoyuanhong@vivo.com

drm/sched: Fix a race in DRM_GPU_SCHED_STAT_NO_HANG test

2025-07-17T09:39:19+00:00

The "skip reset" test waits for the timeout handler to run for the
duration of 2 * MOCK_TIMEOUT, and because the mock scheduler opted to
remove the "skip reset" flag once it fires, this gives opportunity for the
timeout handler to run twice. Second time the job will be removed from the
mock scheduler job list and the drm_mock_sched_advance() call in the test
will fail.

Fix it by making the "don't reset" flag persist for the lifetime of the
job and add a new flag to verify that the code path had executed as
expected.

Signed-off-by: Tvrtko Ursulin 
Fixes: 1472e7549f84 ("drm/sched: Add new test for DRM_GPU_SCHED_STAT_NO_HANG")
Cc: Maíra Canal 
Cc: Philipp Stanner 
Reviewed-by: Maíra Canal 
Signed-off-by: Philipp Stanner 
Link: https://lore.kernel.org/r/20250716084817.56797-1-tvrtko.ursulin@igalia.com

drm/sched: Add new test for DRM_GPU_SCHED_STAT_NO_HANG

2025-07-15T11:27:07+00:00

Add a test to submit a single job against a scheduler with the timeout
configured and verify that if the job is still running, the timeout
handler will skip the reset and allow the job to complete.

Reviewed-by: Tvrtko Ursulin 
Reviewed-by: Philipp Stanner 
Link: https://lore.kernel.org/r/20250714-sched-skip-reset-v6-4-5c5ba4f55039@igalia.com
Signed-off-by: Maíra Canal

drm/sched: Make timeout KUnit tests faster

2025-07-15T11:27:07+00:00

As more KUnit tests are introduced to evaluate the basic capabilities of
the `timedout_job()` hook, the test suite will continue to increase in
duration. To reduce the overall running time of the test suite, decrease
the scheduler's timeout for the timeout tests.

Before this commit:

[15:42:26] Elapsed time: 15.637s total, 0.002s configuring, 10.387s building, 5.229s running

After this commit:

[15:45:26] Elapsed time: 9.263s total, 0.002s configuring, 5.168s building, 4.037s running

Reviewed-by: Tvrtko Ursulin 
Acked-by: Philipp Stanner 
Link: https://lore.kernel.org/r/20250714-sched-skip-reset-v6-3-5c5ba4f55039@igalia.com
Signed-off-by: Maíra Canal