• Paul Mackerras's avatar
    [PATCH] Provide an interface for getting the current tick length · 726c14bf
    Paul Mackerras authored
    This provides an interface for arch code to find out how many
    nanoseconds are going to be added on to xtime by the next call to
    do_timer.  The value returned is a fixed-point number in 52.12 format
    in nanoseconds.  The reason for this format is that it gives the
    full precision that the timekeeping code is using internally.
    
    The motivation for this is to fix a problem that has arisen on 32-bit
    powerpc in that the value returned by do_gettimeofday drifts apart
    from xtime if NTP is being used.  PowerPC is now using a lockless
    do_gettimeofday based on reading the timebase register and performing
    some simple arithmetic.  (This method of getting the time is also
    exported to userspace via the VDSO.)  However, the factor and offset
    it uses were calculated based on the nominal tick length and weren't
    being adjusted when NTP varied the tick length.
    
    Note that 64-bit powerpc has had the lockless do_gettimeofday for a
    long time now.  It also had an extremely hairy routine that got called
    from the 32-bit compat routine for adjtimex, which adjusted the
    factor and offset according to what it thought the timekeeping code
    was going to do.  Not only was this only called if a 32-bit task did
    adjtimex (i.e. not if a 64-bit task did adjtimex), it was also
    duplicating computations from kernel/timer.c and it wasn't clear that
    it was (still) correct.
    
    The simple solution is to ask the timekeeping code how long the
    current jiffy will be on each timer interrupt, after calling
    do_timer.  If this jiffy will be a different length from the last one,
    we then need to compute new values for the factor and offset used in
    the lockless do_gettimeofday.  In this way we can keep xtime and
    do_gettimeofday in sync, even when NTP is varying the tick length.
    
    Note that when adjtimex varies the tick length, it almost always
    introduces the variation from the next tick on.  The only case I could
    see where adjtimex would vary the length of the current tick is when
    an old-style adjtime adjustment is being cancelled.  (It's not clear
    to me why the adjustment has to be cancelled immediately rather than
    from the next tick on.)  Thus I don't see any real need for a hook in
    adjtimex; the rare case of an old-style adjustment being cancelled can
    be fixed up at the next tick.
    Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
    Acked-by: default avatarjohn stultz <johnstul@us.ibm.com>
    Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    726c14bf
timer.c 41 KB