Those pesky top 32 bits of TSC

Jamie Lokier (lkd@tantalophile.demon.co.uk)
Sun, 24 May 1998 23:00:51 +0100


I've seen some mention that because the top 32 bits of TSC can't be
restored after a suspend-to-disk and restart, proper timing can't be
guaranteed around this.

To be honest I'd be surprised if the BIOS attempts to save even the
lower 32 bits. But anyway, let's suppose it does.

Linux _doesn't need_ the top 32 bits for anything. The TSC is used for
intra-jiffy timing only, which is always <2^31 cycles unless something
is broken. Just subtract the last 32 bit time from the current one, let
wraparound handle itself, perhaps clamp, and add that onto "time at last
timer tick".

On a slightly different note, I'm sure it's a right pain that Cyrix and
Centaur chips stop counting when halted. Surely it is no big deal to
switch to `do_slow_gettimeoffset' just before `hlt' is executed, then in
that function lazily switch back to `do_fast_gettimeoffset', estimating
the lost cycles from the slow time just measured. After all, there were
enough CPU cycles spare to do `hlt' in the first place...

Finally, whoever's hacking the time code, I'd suggest a simple adaptive
filter (Kalman, for example) on the "jiffies/TSCs" calibrator in
`do_fast_gettimeoffset' to minimise jitter due to interrupt latency.
And make sure `gettimeofday' ends up monotonic! I spent years working
around non-monotonicity in Linux some time back (couple of years); it may
be fixed these days for all I know though.

-- Jamie

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu