drm/sched: Add some scheduling quality unit tests 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