On 19/03/2026 09:50, Tvrtko Ursulin wrote:
>
>
> 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?
I haven't removed the cyclical nature of workers submitting jobs. I
omitted that part because I thought we already agreed on it.
Anyway, I realized that unfortunately the strategy of using harmonic
periods to overlap submissions makes no sense given how the mock
scheduler serializes jobs into a single "execution" line. I'm now
thinking that using a narrower range of (multiple) submission periods
would be more effective to stress concurrent submissions.
I'm also thinking that splitting the single execution time budget into
equal shares among workers, and then computing the number of jobs that
fit into that share, is simpler and better suited for a test case
compared to a time-based approach. Let me share some pseudocode for
this new approach:
/* Parameters (test_duration must be larger than base_period) */
drm_sched_interleaved_params [...]
{
.num_workers = ... /* 8 to 32 */
.test_duration = ... /* Few seconds */
.base_period = ... /* 100 us, small GPU job */
}
/* Setup phase common for all workers. */
workers_share = params->test_duration / params->num_workers;
/* Worker */
drm_sched_interleaved_worker()
{
period = (worker->id + 1) * base_period;
num_jobs = workers_share / period;
for (i = 0; i < num_jobs; i++) {
drm_mock_sched_job_set_duration_us(period);
/* submit and wait for the job to complete */
}
}
What do you think?
Thanks,
Marco
