From mboxrd@z Thu Jan 1 00:00:00 1970 From: jan.kiszka@web.de (Jan Kiszka) Date: Tue, 02 Dec 2008 23:10:39 +0100 Subject: [ltt-dev] trace a futex In-Reply-To: <20081202215519.GA734@Krystal> References: <8d94e9280812021142j2eb5ca72td730410e97ccd9a1@mail.gmail.com> <20081202195015.GA25792@Krystal> <8d94e9280812021215m6a63d6c2l4e64acd26274953d@mail.gmail.com> <20081202215519.GA734@Krystal> Message-ID: <4935B25F.7010701@web.de> Message-ID: <20081202221039.32zucnQuTG4LX6rsR8vKEFPoGaFv8D93lptbnEjEK8M@z> Mathieu Desnoyers wrote: > * Gian Lorenzo Meocci (glmeocci at gmail.com) wrote: >> Hi Mathieu, >> >> thanks for your reply. >> >> I want specify that: >> 1) I am already patching glibc (and, of course, nptl/pthread_*) >> 2) I already add two event to pthread_mutex_lock. The first at the >> beginning of the function and the second after all return 0 presented >> on that function. But those two events are not enough to establish if >> a pthread_mutex_lock has been blocking. >> In fact I know only the time spent on pthread_mutex_lock. If this time >> is little probably I hold the mutex otherwise I was been descheduled. >> >> So thanks a lot again, >> >> > > Ok, then you will probably want to correlate your information with : > > - scheduling activity regarding your threads > - system call entry events, especially sys_futex. Note that a thread > calling sys_futex won't _necessarily_ be put to sleep.. it may still > be able to take the lock relatively quickly. > > If you need more than that, we may think of instrumenting futex.c, but I > am not sure this is required. Haven't checked the state of instrumentation recently: Is the futex operation visible in the trace now? It used to be not, and we often had to guess the reason for sys_futex (wake, wait, pi or not pi, etc.) from the context - or add ad-hoc instrumentation. Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 257 bytes Desc: OpenPGP digital signature URL: