This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
RE: Out of order timings of gettimeofday_us()
- From: "Stone, Joshua I" <joshua dot i dot stone at intel dot com>
- To: <ndebard at lanl dot gov>
- Cc: <systemtap at sourceware dot org>
- Date: Tue, 23 Jan 2007 17:03:52 -0800
- Subject: RE: Out of order timings of gettimeofday_us()
On Tuesday, January 23, 2007 2:34 PM, Nathan A. Debardeleben wrote:
> I have a very simple script which seems to demonstrate time values
> coming out of gettimeofday_us() being out of order. I believe this
> function I am probing is extremely fast - but, regardless, it
> shouldn't take negative time to complete. :)
>
> [...]
>
> Is the us() timing just too fine grained? If it's acting like this
> here I question its values in other places.
The short answer is that I'm not too surprised that you got negative
values, and I'm not sure we can do anything about it. If you need
fine-grained measurement, perhaps get_cycles() would work better for
you?
The time functions are really a "best estimate" -- see this bug for a
little history:
http://sources.redhat.com/bugzilla/show_bug.cgi?id=2525
We can't use the kernel's gettimeofday, because it grabs xtime_lock --
our functions must be callable from ANY context, and they'll deadlock if
that lock is already held.
So, our time functions make an estimate based on get_cycles(), the
current frequency, and the kernel's gettimeofday from the last time we
synced (every jiffies tick). This is imperfect, but safe. I would
welcome any different designs that still meets our needs though --
perhaps we can give LKML a gettimeofday variant that avoids the lock?
Inaccuracies will arise if your measurement straddles the sync-point,
especially if the frequency we're using isn't quite correct. If we
underestimate the frequency, then we'll overestimate how much time has
elapsed, so when the sync happens it might backtrack a bit.
Josh