On Nov 7, 2007 6:22 PM, Roman Shaposhnik <[EMAIL PROTECTED]> wrote: > 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.
OK :) > 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. Agreed. We don't have Neelam's code so we don't know exactly what it does. So there's too much guess work. > 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. I believe the overhead of firing a probe from userspace to the DTrace framework is in the order of thousands of cycles. But I don't have access to a Solaris system right now so I don't know. Whether DTrace is good enough or not all depends on how long the lock is held. I am interested in your experiment as well... Rayson > > 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]
