[LTP] [PATCH] syscalls/clock_gettime: Add test to check bug during successive readings

Arnd Bergmann arnd@arndb.de
Tue Jun 9 09:43:22 CEST 2020


On Tue, Jun 9, 2020 at 9:05 AM Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> On 08-06-20, 16:51, Arnd Bergmann wrote:
> > You already have a special case for gettimeofday(), so just round down
> > the 'start' value to the previous microsecond when you are in that
> > case.
>
> Since this will also affect the next reading as well (as we will loose
> values < 1 us), I tried to do it a bit differently.
>
> @@ -78,6 +78,13 @@ static void run(unsigned int i)
>                         tv->gettime(clks[i], tst_ts_get(&ts));
>                         end = tst_ts_to_ns(ts);
>
> +                       /*
> +                        * gettimeofday() doesn't value less than 1 us, copy
> +                        * that from start.
> +                        */
> +                       if (tv->gettime == my_gettimeofday && end < start)
> +                               end += start % 1000;

This looks like it should work correctly, but it feels a bit more fragile than

                       if (tv->gettime == my_gettimeofday)
                               start -= start % 1000;

which would bring the start and end values to the same resolution
rather than making up values that were never read.

Your approach however has the advantage of adding less overhead
as the % operator on a 64-bit integer is going to turn into a very
expensive calculation on most 32-bit processors that itself can
skew the timing.

> > > +                       /* Skip comparison on first traversal */
> > > +                       if (count == 10000 && !j)
> > > +                               continue;
>
> I am skipping diff for the first iteration..
>
> > > +
> > > +                       diff = end - start;
> >
> > I think on the first iteration, 'start' is wrong here as well, and needs to
> > be initialized once, as you did in the earlier versions.
>
> And so this won't be a problem.

Ok.

        Arnd


More information about the ltp mailing list