We do no such thing.
Guys, the heartbeat is a _separate_ thing from overflow handling.
You don't handle overflow by having a heartbeat that beats fifty times a
second just to insert events, just so that the TSC delta would always fit
in 27 bits. That would work, but be stupid. It would mean that you fill up
your event buffer with uninteresting crud just because nothing happens.
Yes, many people want to have a heartbeat (a "Mark" event) every once in a
while, but what I suggest is independent of heartbeats, even if it _could_
be implemented that way. What I suggest is simply that when you insert an
event, you always read the full 64 bits of TSC (on x86 - others will do
other things), and then you insert the delta against the last one.
After all, you cannot read just 27 bits of the TSC anyway. You _have_ to
read the whole 64 bits, and then you subtract the pervious trace event TSC
(that you have in the per-CPU trace buffer header) from that. You now have
a delta value.
And if the delta doesn't fit in 27 bits, you generate a 59-bit TSC event!
None of this has _anything_ to do with interrupt latency. There is no
dependency on a heartbeat, or any dependency on always inserting a trace
event at least 30 times a second. There's no worry about conversions, and
these are all trivial single assembly instructions to do (or a couple, on
a 32-bit architecture that needs to do a sub/sbb pair and test two
different registers to see if the result fits in 27 bits).
The only issue is that if you insert trace events more seldom, you'll
always get the extra TSC event as well, inserted automatically in front of
the event you explicitly inserted. The tracer doesn't need to know.
Linus
--
