On Wed, 2007-11-07 at 16:24 -0500, Rayson Ho wrote: > On Nov 7, 2007 4:17 PM, Roman Shaposhnik <[EMAIL PROTECTED]> wrote: > > I have troubles correlating the two statements you've made. Is it that > > you're suggesting NOT to use DTrace because it is slower than manually > > inserted timing calls around each pthread_mutex_[un]lock ? > > Well... Where did I say that??
I didn't imply you did. I felt confused about your two statements and offered you an interpretation of them that seemed to fit hoping that it would be a useful first step to understanding what you actually had in mind. > I am helping Neelam to understand the problem. You sure don't want to > use a stop watch to measure the latency of a cache miss, do you?? No, but I can used DTrace (well, almost -- the CPC provider is still not part of the default setup) ;-) > By the same token, if the overhead of getting to DTrace from the > userland Do you have proof that the overhead is as great as you make it look? pthread_* operations are not exactly cheap. Even in userspace. Besides, the lock duration time is usually a relative value anyway. I ran an experiment once using rdtsc assembly instruction for manually timing some mid-frequency user-space operations with and without DTrace enabled. The difference was there (and I shouldn't say it was negligible) but it wasn't all that impressive. I'd be curious to hear your side of the story. Thanks, Roman. P.S. As for the tools applicable to the problem at hand one can always use Sun Studio Performance Analyzer if small dilation is of a top concern and all that's needed is user-space application analysis. _______________________________________________ dtrace-discuss mailing list [email protected]
