Re: [RFC PATCH 1/3] Unified trace buffer

[Steven Rostedt]

On Thu, 25 Sep 2008, Linus Torvalds wrote:
> 
> 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!

Note: RFC v2 implements this.

-- Steve

> 
> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/