On Wed, 2007-11-07 at 12:35 -0800, Neelam wrote:
> You can see two release probes here, because I was trying to find out the
> duration of outermost lock, when there is nesting.
>
> And for the timing measurement in the c code, I think it must be the user
> level gethrtime()..I include #include <sys/time.h> for using it.
First of all -- your script looks reasonable, so the only possible
explanation I could come up with would be: there's a hard to reproduce
bug in DTrace that makes timestamp disagree with gethrtime() on
some 64bit architectures (we observed it on a Solaris Nevada
running on a 64bit Acer laptop). The easiest way to verify
whether you're affected by it or not is to run the following set
of commands:
$ cat q.c
#include <sys/time.h>
#include <stdio.h>
#include <inttypes.h>
int main()
{
while (1) {
printf("uspace -> %llx\n", gethrtime());
sleep(1);
}
}
$ cc [-m64 depending on whether your actual app is 64bit] q.c
$ dtrace -qn 'pid$pid:libc.so:gethrtime:entry { \
printf("dtrace -> %llx\n", (uint64_t)timestamp); }' -c ./a.out
Let it run for at least a minute and observe numbers. If the numbers you
get with dtrace -> and uspace -> prefixes seems to disagree you've
got that problem.
Thanks,
Roman.
_______________________________________________
dtrace-discuss mailing list
[email protected]
