[lkml]   [2008]   [Apr]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: gettimeofday() jumping into the future
    On Thu, Apr 3, 2008 at 5:44 AM, James Courtier-Dutton
    <> wrote:
    > It should be:
    > treat cycle_now and cycle_last as unsigned.
    > unsigned tmp;
    > tmp = cycle_now - cycle_last;
    > if (tmp > max_difference_threshold) cycle_now = cycle_last;
    > This correctly handles cycle_now going backwards as well as wrap around.
    > The only way to catch all edge cases is to be able to make an assumption
    > on the maximum acceptable difference between cycle_now and cycle_last,
    > where difference is the shortest distance between values if they were
    > pointers into a ring buffer. The other assumption made here is that the
    > wrap around only happens at max_uint of cycle_now.

    Yea. I see Thomas' patch was applied then reverted as it caused
    problems with the TSC reseting over suspend and resume (since the
    timekeeping core doesn't have a hook into the tsc clocksource to
    inform it that the comparision is invalid, so the resume-time read
    will always return the cycle_last value and not the actual smaller TSC

    This suggested bounding of how much a negative value is considered
    valid would resolve this issue, since really the scope of this fix is
    very small negative offsets due to the TSC being ever so slightly out
    of sync between processors (but not enough to warrent throwing the TSC
    out as a valid clock source).


     \ /
      Last update: 2008-04-12 01:13    [W:0.022 / U:146.500 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site