Re: [PATCH] drm/sched: Add new KUnit test suite for concurrent job submission

[Tvrtko Ursulin]

On 18/03/2026 17:23, Marco Pagani wrote:

8><

Alternative approach could be to set a per test time budget and just
keep the workers submitting until over. It would be simpler to
understand and there would be more submit/complete overlap.

I agree. Using a test time budget and having workers continuously
submit jobs until it expires would make better use of the test time.
I'm thinking that the simplest and most straightforward approach would
be to cyclically distribute periods among workers until they reach the
the largest possibile value below test duration, which would coincide
with the hyperperiod. This would also solve the issue of selecting a
suitable periods_cycle parameter that you mentioned earlier.
In practice, something like this:

drm_sched_interleaved_params [...]
{
          .num_workers = N
          .test_max_time = T
          .job_base_period_us = P         /* Small GPU job, 100 us */
}

period_us = job_base_period_us;
for (i = 0; i < params->num_workers; i++) {
          workers[i].period_us = period_us;
          period_us *= 2;
          if (period_us > test_max_time)
                  period_us = job_base_period_us;
}


What do you think?


Again some time has passed so rather than going to re-read your patch I
will go from memory. IIRC I was thinking something really dumb and 100%
time bound with no need to think when coding and reviewing. Each thread
simply does:

ktime_t start = ktime_get();

do {
   .. thread doing its submission pattern thing ..
} while (ktime_to_ms(ktime_sub(ktime_get(), start)) < test->time_ms);

May miss the time target by a job period_us but who cares.

Sorry for the delay. I got pulled into other things. I left out the worker
execution part since we already agreed on that. Instead, I've replied with
some pseudocode describing a new strategy for period assignments from test
parameters that takes into account your comments.

Sorry I misread when I saw test_max_time clamping I thought it was about 
runtime control. I guess it makes sense to clamp it to avoid 
over-shooting by too much. You removed the cyclical nature so I guess in 
practice this will not happen? I mean number of workers vs base period 
you don't expect more than one of them to get clamped?

Regards,

Tvrtko