Re: More weird latency trace output (was Re: 2.6.17-rt1)

[Ingo Molnar]

* Lee Revell <rlrevell@xxxxxxxxxxx> wrote:

> On Thu, 2006-06-22 at 21:24 -0400, Lee Revell wrote:
> > On Wed, 2006-06-21 at 22:51 -0400, Lee Revell wrote:
> > > How can the latency tracer be reporting 1898us max latency while the
> > > trace is of a 12us latency?  This must be a bug, correct?
> > 
> > I've found the bug.  The latency tracer uses get_cycles() for
> > timestamping, which uses rdtsc, which is unusable for timing on dual
> > core AMD64 machines due to the well known "unsynced TSCs" hardware bug.
> > 
> > Would a patch to convert the latency tracer to use gettimeofday() be
> > acceptable?
> 
> OK, I tried that and it oopses on boot - presumably the latency tracer 
> runs before clocksource infrastructure is initialized.
> 
> Does anyone have any suggestions at all as to what a proper solution 
> would look like?  Is no one interested in this problem?

does it get better if you boot with idle=poll? [that could work around 
the rdtsc drifting problem] Calling gettimeofday() from within the 
tracer is close to impossible - way too many opportunities for 
recursion. It's also pretty slow that way.

	Ingo
-
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/