[PATCH v3 3/8] drm/sched: Make timeout KUnit tests faster

[Maíra Canal]

Hi Philipp,

On 30/06/25 09:20, Philipp Stanner wrote:
> On Mon, 2025-06-30 at 09:05 -0300, Maíra Canal wrote:
>> Hi Philipp,
>>
>> On 30/06/25 08:53, Philipp Stanner wrote:
>>> On Wed, 2025-06-18 at 11:47 -0300, Maíra Canal wrote:
>>>> 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
>>>
>>> I guess those times were measured with the entire series?
>>
>> No, they were measured without the new test that I introduced in the
>> next patch.
>>
>>>
>>> It's not clear to me whether this patch is independent from the
>>> series.
>>> I suppose it is. We should aim towards having series's narrowly
>>> focused
>>> topic-wise, but I get why you included it here.
>>
>>   From my perspective, this patch is a preparation to the next one. As
>> I'll introduce another timeout-related test in the next patch, I was
>> trying to ensure that we will keep the time-budget reasonable.
>>
>>>
>>> That said, is there a specific reason for you aiming at ~10s
>>> (9.263)?
>>> That's only a bit faster than the 15.637.
>>>
>>
>> Actually, the only thing that this patch affects is the runtime. So,
>> it
>> went from 5.229s to 4.037s (-22.8%). However, as we add more and more
>> timeout tests, the absolute difference would get more significant.
> 
> I understand that. My point is that the decrease of total run time that
> you state in your commit message doesn't sound that significant to me.
> ~10s is still pretty long.
> 
>>
>>> Couldn't it make sense, as you're at it already, to speed this up
>>> to
>>> just a few seconds, like 3-5? Then it should really be quiet IRW
>>> that
>>> topic for a while.
>>
>> I believe that further decreasing the timeout could lead to racy
>> scenarios and flaky tests.
> 
> That doesn't make sense to me. What could race with what? I guess you
> mean the completion's timeout racing with the signaling timer.

I discussed a bit about it with Tvrtko in v1 [1][2].

[1] 
https://lore.kernel.org/all/7cc3cc3d-7f67-4c69-bccb-32133e1d7cba@igalia.com/
[2] 
https://lore.kernel.org/all/146f3943-0a94-4399-9f49-be8228a86828@igalia.com/

Best Regards,
- Maíra

> 
> Anyways, I'm personally not suffering from the tests being too slow. So
> just take this as ideas. I'm fine with it being merged as it is now.
> 
> 
> P.
> 
>>
>> Best Regards,
>> - Maíra
>>
>>>
>>>
>>> P.
>>>