gethrtime() is implemented as a "Fast Trap System Call", but
timestamp() in DTrace needs to go deeper into the kernel...
I only have the 1st edition of the "Solaris Internals" book, but the
conparsion (on page 47) of a fast trap system call vs a getpid() on a
300 MHz Ultra2:
latency (ns)
getpid() 2138
gethrtime() 320
lib C call 93
Since the overhead of gethrtime() is relative cheap compare to a
normal system call, the time difference may come from the difference
in overhead between the two...
Rayson
On Nov 6, 2007 7:37 PM, Neelam <[EMAIL PROTECTED]> wrote:
> I am using timestamp() in DTrace for timing some events, in particular
> duration of a lock (i.e. time elapsed between the acquisition and release of
> a mutex lock). I am getting pretty high numbers. But when I time the lock by
> explicitly using timing functions such as gethrtime(), I get pretty low
> numbers. Does this mean timestamp() doesn't give us the accurate
> measurements? What are the alternatives?
_______________________________________________
dtrace-discuss mailing list
[email protected]
