[LTP] [PATCH v3 22/29] fuzzy_sync: Convert to runtime

Cyril Hrubis chrubis@suse.cz
Tue May 17 12:56:27 CEST 2022


Hi!
> >> I guess the root cause is that 'pair->time_exec_start' has a possibility
> >> to reach zero. in pty03 it has ".tcnt = 9" which made the
> >> tst_fzsync_pair_reset()
> >> to be re-run many times, but in that function 'pair->time_exec_start' will
> >> be set only based on the original .max_runtime, with time elapsed the
> >> remaining time tends to be zero.
> >
> > I guess that that the interaction of tcnt and runtime is not optimal
> > here. You are right that as long as we call tst_fzsync_pair_reset() on
> > each invocation of the run() function we may eventually get to state
> > where the runtime is exhausted, especially on slower hardware we end up
> > with division by zero and overflow.
> >
> > The cleanest solution would be to rewrite the test to use .test_variants = 9
> > and setting the .max_runtime to a smaller value. That way we would have
> > precisely defined runtime for each iteration. What do you think?
> 
> Or each test case (defined by tcnt) could be given an equal share of the
> runtime?

That would be solution as well. If everyone agrees on this I will go
with this version, it should be as easy as:

diff --git a/lib/tst_test.c b/lib/tst_test.c
index dad8aad92..69d7799c3 100644
--- a/lib/tst_test.c
+++ b/lib/tst_test.c
@@ -1349,6 +1349,8 @@ static void run_tests(void)

                if (results_equal(&saved_results, results))
                        tst_brk(TBROK, "Test %i haven't reported results!", i);
+
+               kill(getppid(), SIGUSR1);
        }
 }


With this we do reset the test timeout after each test iteration.

-- 
Cyril Hrubis
chrubis@suse.cz


More information about the ltp mailing list