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/[email protected]/
[2]
https://lore.kernel.org/all/[email protected]/
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.
