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

[Li Wang]

Cyril Hrubis <chrubis@suse.cz> wrote:


> > > -       if (pair->exec_time_p < rem_p) {
> > > +       if (rem_p >= 1) {
> > >
> >
> > 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.


debug log
--------------
../../../include/tst_fuzzy_sync.h:651: TINFO: rem_p is 0.000000
../../../include/tst_fuzzy_sync.h:651: TINFO: rem_p is 0.000000
../../../include/tst_fuzzy_sync.h:651: TINFO: rem_p is 1.000000
../../../include/tst_fuzzy_sync.h:654: TINFO: Exceeded execution time,
requesting exit
pty03.c:132: TPASS: Did not crash with PPS TTY discipline
pty03.c:106: TINFO: Creating PTY with CAIF line discipline
../../../include/tst_fuzzy_sync.h:651: TINFO: rem_p is -nan
pty03.c:91: TCONF: You don't appear to have the CAIF TTY line discipline:
EINVAL (22)
pty03.c:106: TINFO: Creating PTY with GSM line discipline
../../../include/tst_fuzzy_sync.h:651: TINFO: rem_p is -nan
../../../include/tst_fuzzy_sync.h:651: TINFO: rem_p is -nan
../../../include/tst_fuzzy_sync.h:651: TINFO: rem_p is -nan



>
>
> And the tst_remaining_runtime() should return 0 once the time is up so
> the end result should be that rem_p will end up 1 sooner or later.
>

Yes, the pair->time_exec_start will be reset to 0 as well then
becomes the denominator. That makes rem_p get an overflowed
negative number, then the test falls into an infinite loop from this moment.



>
> Anyways we can as well use the value from tst_remainig_runtime()
> directly instead as:


> diff --git a/include/tst_fuzzy_sync.h b/include/tst_fuzzy_sync.h
> index bef424002..db5bec7a4 100644
> --- a/include/tst_fuzzy_sync.h
> +++ b/include/tst_fuzzy_sync.h
> @@ -634,7 +634,8 @@ static inline void tst_fzsync_wait_b(struct
> tst_fzsync_pair *pair)
>   */
>  static inline int tst_fzsync_run_a(struct tst_fzsync_pair *pair)
>  {
> -       float rem_p = 1 - tst_remaining_runtime() / pair->exec_time_start;
> +       int remaining_runtime = tst_remaining_runtime();
> +       float rem_p = 1 - remaining_runtime / pair->exec_time_start;
>
>         if ((SAMPLING_SLICE < rem_p) && (pair->sampling > 0)) {
>                 tst_res(TINFO, "Stopped sampling at %d (out of %d)
> samples, "
> @@ -644,7 +645,7 @@ static inline int tst_fzsync_run_a(struct
> tst_fzsync_pair *pair)
>                 tst_fzsync_pair_info(pair);
>         }
>
> -       if (rem_p >= 1) {
> +       if (!remaining_runtime) {
>                 tst_res(TINFO,
>                         "Exceeded execution time, requesting exit");
>                 tst_atomic_store(1, &pair->exit);
>
>
> Does that fix your problem?
>

This amendment is more readable but does not solve the original problem.

-- 
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20220513/0d1a8439/attachment-0001.htm>