[LTP] [PATCH V3] lib: multiply the max_runtime if detect slow kconfigs
Li Wang
liwang@redhat.com
Fri Dec 20 08:19:24 CET 2024
On Fri, Dec 20, 2024 at 11:59 AM Li Wang <liwang@redhat.com> wrote:
> Hi All,
>
> It suddenly occurred to me that we might be on the wrong track in
> solving the timeout problem. Because 'max_runtime' is intended to
> set the expected runtime for the main part of the test, and is also
> used as the loop termination time by tst_remaining_time(). So the
> multiplier has a side effect of extending the looping time of many tests.
>
> But our original intention was to avoid test timeouts on slow systems
> (e.g. debug kernels), and the timeout is a hard upper bound to prevent
> the test from hanging indefinitely due to environmental factors
> (e.g., slow systems, kernel debug mode).
>
> So, shouldn't we only target to extend the timeout value?
>
>
> --- a/lib/tst_test.c
> +++ b/lib/tst_test.c
> @@ -555,9 +555,6 @@ static int multiply_runtime(int max_runtime)
>
> parse_mul(&runtime_mul, "LTP_RUNTIME_MUL", 0.0099, 100);
>
> - if (tst_has_slow_kconfig())
> - max_runtime *= 4;
> -
> return max_runtime * runtime_mul;
> }
>
> @@ -1706,6 +1703,9 @@ unsigned int tst_multiply_timeout(unsigned int
> timeout)
> if (timeout < 1)
> tst_brk(TBROK, "timeout must to be >= 1! (%d)", timeout);
>
> + if (tst_has_slow_kconfig())
> + timeout *= 4;
> +
> return timeout * timeout_mul;
> }
>
Regarding the starvation.c test, is not a common issue, the test
using max_runtime to complete 1000000 loops in such required
time slot to judge FAIL or PASS is not perfect, while the debug
kernel will throw a false positive once the runtime is not enough
for looping.
It's not about finding the right max_runtime value for all scenarios,
which interferes with our sight. Because their callibrate() doesn't
have much difference from general or debug kernel evaluation, it
only relies on CPU models.
We can treat it as a dedicated case or skip from debug-kernel directly.
--
Regards,
Li Wang
More information about the ltp
mailing list