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

Richard Palethorpe rpalethorpe@suse.de
Mon May 16 09:52:26 CEST 2022


Hello,

Cyril Hrubis <chrubis@suse.cz> writes:

> Hi!
>> > > I hit a new problem while testing new pty03, that seems here
>> > > will fall into an infinite loop and test timed out finally. The printf
>> > > shows rem_p will be overflow I haven't figured out why.
>> > >
>> > > But with comparing with 0.9, it always gets passed on to the same system.
>> >
>> > That is strange, since we do:
>> >
>> >         rem_p = 1 - tst_remaining_runtime()/pair->time_exec_start;
>> >
>> 
>> 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?

-- 
Thank you,
Richard.


More information about the ltp mailing list