Messages in this thread | | | Date | Thu, 25 Sep 2008 09:49:39 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: [RFC PATCH 1/3] Unified trace buffer |
| |
On Thu, 25 Sep 2008, Mathieu Desnoyers wrote: > > I remembered other concerns about 27 vs 32 bits TSC decision, which are > rather important. First, if we have a 27 bits TSC, with overflow every > 33ms at 4GHz, we assume the kernel will _never_ have an interrupt > latency longer than this for correct heartbeat behavior.
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
| |