[LTP] [REGRESSION] pidns05 timeout (was: [PATCH 1/2] lib: multiply the timeout if detect slow kconfigs)

[Petr Vorel]

> On Thu, Jan 16, 2025 at 6:42 AM Petr Vorel <pvorel@suse.cz> wrote:

> > Hi Li, Cyril, all,

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

> > FYI this change, merged as 893ca0abe7 ("lib: multiply the timeout if
> > detect slow
> > kconfigs") caused a regression on *all* tests which use tst_net.sh.
...

FYI also at least pidns05.c sometimes fails due timeout with this change.
On some of SLES product previously pidns05.c run for 3 sec. With this change it
runs 12s and therefore timeouts.

In pidns05.c case child is run 5x. For each of this child we again detect if we
run on slow config. Maybe we should have used struct tst_test member to cache
the value.

What bothers me more that how much time we waste for whole LTP testing with
repeatedly detecting slow config for all tests (runtest/syscalls has 1457 items,
we run it more times for each product with different kernel cmdline parameters).
I don't know what was supposed to be fixed by this feature, is it really worth
of slowdown? Why not just set LTP_RUNTIME_MUL=2 on slow kernels? We could have
tool which would 'exit 1' on "slow" kernel and 'exit 0' on normal kernel to do
automatic detection, which could be run by frameworks just once.

Kind regards,
Petr