[LTP] [RFC PATCh] lib: redefine the overall timeout logic of test

[Li Wang]

On Wed, Jan 8, 2025 at 8:29 PM Cyril Hrubis <chrubis@suse.cz> wrote:

> Hi!
> > > Btw, we have some tests that implicitly invoke tst_remaining_runtime,
> > > for example, using the fuzzy_sync library, which also needs .runtime
> > > but not .timeout.
> > >
> >
> > Also, tests that use 'test.runtime' directly (e.g. readahead02.c,
> > set_mempolicy01.c)
> > must continue to be marked as using .runtime.
>
> I think that readahead02 is a case where we should switch to timeout
> because that is exactly the situation where want the timeout to be
> multiplied when the system is slower. The way the test adjust the
> runtime dynamically is wrong anyways, because it increases the timeout
> for each iteration. We should just put the worstcase runtime into the
> .timeout instead.
>

I have a different view on the readahead02 test, because the runtime
resetting is based on pieces of each IO test elapsed time, then reset
runtime for next time. This applies to any kernels, no matter the faster
or slower, the elapsed time will be enough for the next tcases[].

If we put the worst-case runtime into .timeout and reset for the next
tcases[], which will be multiplied again on debug kernel, actually we
don't need that since the dynamic runtime comes from a real test.

Maybe I missed something in the test, but we can treat readahead02
in a separate work. The new patch 4/4 should be modified using .runtime
instead of .timeout. Feel free to comment your thoughts there.



>
> And similarily for the the mempolicy it looks like we should set the
> timeout dynamicaly in the testup with tst_set_timeout() instead of
> runtime.
>

Agreed this change on mempolicy01.c.


-- 
Regards,
Li Wang