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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


* Lee Revell <[email protected]> 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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at
Please read the FAQ at

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux