On Fri, Mar 31, 2017 at 2:32 AM, Nicolai Hähnle <[email protected]> wrote: > On 30.03.2017 15:03, Ilia Mirkin wrote: >> >> On Thu, Mar 30, 2017 at 8:19 AM, Nicolai Hähnle <[email protected]> >> wrote: >>> >>> On 30.03.2017 14:07, Ilia Mirkin wrote: >>>> >>>> >>>> Time could roll over... not sure what to do about that though. Maybe >>>> check if the top 2 bits are set in the old value and are unset in the >>>> new value, and hope that the counter precision > 2 bits? [It'd be >>>> unfortunate for CIs to get occasional failures in these tests...] >>> >>> >>> >>> Shouldn't roll-over be covered by the cast to int followed by comparison >>> with 0? >> >> >> Let's say start_time == 0xfffffffffffffff, late_time = 0. Perhaps I'm >> getting the math wrong here, but as far as I can see, that test will >> fail. > > > + int64_t diff = int64_t(late_time - start_time); > + > + if (diff <= 0l) > + atomicCounterIncrement(bad); > > In your example, we get late_time - start_time == 0 - uint64_t(-1) == 1, so > the atomic increment of bad doesn't happen.
Right. So unless the counter goes REALLY fast (or is a single bit), this should be pretty safe. This series is Reviewed-by: Ilia Mirkin <[email protected]> > > Cheers, > Nicolai > >> >> -ilia >> > > > -- > Lerne, wie die Welt wirklich ist, > Aber vergiss niemals, wie sie sein sollte. _______________________________________________ Piglit mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/piglit
