No, as I said: "You just need to emit the current
tsc+frequency+wallclock time before you emit any more delta records
after the frequency change."
When an event which affects the tsc occurs, like a frequency change or
pause, set a flag. When you're next about to emit a delta, check the
flag and emit new timing parameters (or instead).
No, you only need to emit records as needed.
You need to know the frequency at the time you sample the tsc, and you
need to know when the frequency changes. If you don't, you can't use
the tsc for time, regardless of whether you process it immediately or
post-process it.
Right. You store (GTOD,freq,tsc) every time you need that information,
and then interpolate with the tsc while you know its monotonic.
Unless your tsc is completely screwed, the (GTOD,freq,tsc) triple is
going to be stored at a fairly low frequency, and won't fill your event
buffer very much (though it might be a large proportion of your recorded
events if you're only recording stuff at a low frequency).
Well, whatever the best timer the platform has. And maybe its already
processed into real time, in which case you just emit raw deltas and
never worry about updating the timing parameters.
Yeah. The scheme relies on a cpu's tsc remaining the cpu's tsc.
Well, its what Xen does already for time. It works well.
J
--
