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

[Philipp Stanner]

On Mon, 2025-06-30 at 11:04 -0300, Maíra Canal wrote:
> 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/


Thx, thought about it, makes sense.

Acked-by: Philipp Stanner <phasta at kernel.org>

> 
> 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.
> > > > 
> 
>