lkml.org 
[lkml]   [2005]   [Oct]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: sched_clock -> check_tsc_unstable -> tsc_read_c3_time ?!?

* Lee Revell <rlrevell@joe-job.com> wrote:

> On Thu, 2005-10-13 at 13:11 -0700, john stultz wrote:
> > Yea, you're right about the inlining. Although I'm not sure why those
> > functions should take microseconds to execute. That's very strange.
>
> Latency tracing overhead plus a slow (600MHz) machine?

yeah. The micro-timings of latency tracing can be misleading. Function
calls are very fast on most CPUs (even on a 600MHz one), but with the
latency tracer generating one trace entry per function call, there's
considerable added overhead.

we could in theory calibrate the tracing overhead and subtract it from
cycle readings [i've done this in a previous mcount() based tracer
implementation, years ago], but that would make the latency trace
timestamps less useful as a global time reference.

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

\
 
 \ /
  Last update: 2005-10-14 06:39    [W:0.461 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site