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-32133e1d7...@igalia.com/ > [2] > https://lore.kernel.org/all/146f3943-0a94-4399-9f49-be8228a86...@igalia.com/
Thx, thought about it, makes sense. Acked-by: Philipp Stanner <pha...@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. > > > > > >
