Rayson Ho wrote: > 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...
I'm fairly sure that that is not the case - all the measurement DTrace does is actually done inside the kernel, so the above will not apply. I also believe that there's be confision here, as there's a kernel *and* a userland version of gethrtime(), and from context, I believe Rayson and Neelam are talking about different ones :-) I'm inclined to believe that, compared to gethrtime(9F), DTrace instrumentation can be quite "heavy" (again, depending on your specific probe), and may in fact influence the results. Please show us the exact script, so we can see whether this assumption helps. Michael > > 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] -- Michael Schuster Sun Microsystems, Inc. recursion, n: see 'recursion' _______________________________________________ dtrace-discuss mailing list [email protected]
