Messages in this thread |  | | Date | Mon, 31 Mar 2008 10:55:33 +0200 (CEST) | From | Thomas Gleixner <> | Subject | Re: gettimeofday() jumping into the future |
| |
On Sun, 30 Mar 2008, Tim Ricketts wrote: > On Thu, 23 Aug 2007, Michael Smith wrote: > > > We've been seeing some strange behaviour on some of our applications > > recently. I've tracked this down to gettimeofday() returning spurious > > values occasionally. > > > > Specifically, gettimeofday() will suddenly, for a single call, return > > a value about 4398 seconds (~1 hour 13 minutes) in the future. The > > following call goes back to a normal value. > > I have also seen this. > > > This seems to be occurring when the clock source goes slightly > > backwards for a single call. In > > kernel/time/timekeeping.c:__get_nsec_offset(), we have this: > > cycle_delta = (cycle_now - clock->cycle_last) & clock->mask; > > > > So a small decrease in time here will (this is all unsigned > > arithmetic) give us a very large cycle_delta. cyc2ns() then multiplies > > this by some value, then right shifts by 22. The resulting value (in > > nanoseconds) is approximately 4398 seconds; this gets added on to the > > xtime value, giving us our jump into the future. The next call to > > gettimeofday() returns to normal as we don't have this huge nanosecond > > offset. > > Indeed. I don't know where the suggestion of off by 2^32us came in > later in this thread. As you've already pointed out, it's off by > 2^42ns. > > I've no idea why the TSC might go backwards, but perhaps we should not > break horribly if it does. How about treating it as zero?
> + if (cycle_now < clock->cycle_last) > + return 0; > +
No, this breaks wrapping clocksources e.g. pmtimer. We need a different sanity check for that TSC crap.
Thanks,
tglx
|  |