From mboxrd@z Thu Jan 1 00:00:00 1970 From: compudj@krystal.dyndns.org (Mathieu Desnoyers) Date: Wed, 3 Dec 2008 00:26:40 -0500 Subject: [ltt-dev] trace a futex In-Reply-To: <4935B25F.7010701@web.de> References: <8d94e9280812021142j2eb5ca72td730410e97ccd9a1@mail.gmail.com> <20081202195015.GA25792@Krystal> <8d94e9280812021215m6a63d6c2l4e64acd26274953d@mail.gmail.com> <20081202215519.GA734@Krystal> <4935B25F.7010701@web.de> Message-ID: <20081203052640.GA13701@Krystal> * Jan Kiszka (jan.kiszka at web.de) wrote: > 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 > It still isn't instrumented, and I think it would be good to add such instrumentation. Have a look at the patch done by K. Prasad for futex.c : it should probably be updated so it uses tracepoints instead of markers. Anyone would like to do this ? See http://lkml.org/lkml/2008/4/15/125 "[RFC PATCH 0/2] Debugging infrastructure for Futexes using Markers" Mathieu -- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From mboxrd@z Thu Jan 1 00:00:00 1970 From: compudj@krystal.dyndns.org (Mathieu Desnoyers) Date: Wed, 3 Dec 2008 00:26:40 -0500 Subject: [ltt-dev] trace a futex In-Reply-To: <4935B25F.7010701@web.de> References: <8d94e9280812021142j2eb5ca72td730410e97ccd9a1@mail.gmail.com> <20081202195015.GA25792@Krystal> <8d94e9280812021215m6a63d6c2l4e64acd26274953d@mail.gmail.com> <20081202215519.GA734@Krystal> <4935B25F.7010701@web.de> Message-ID: <20081203052640.GA13701@Krystal> Message-ID: <20081203052640.YYCBQZrdHeHIcZX0XwlfMIVqz6VmXEW-JYIVUOkes3c@z> * Jan Kiszka (jan.kiszka at web.de) wrote: > 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 > It still isn't instrumented, and I think it would be good to add such instrumentation. Have a look at the patch done by K. Prasad for futex.c : it should probably be updated so it uses tracepoints instead of markers. Anyone would like to do this ? See http://lkml.org/lkml/2008/4/15/125 "[RFC PATCH 0/2] Debugging infrastructure for Futexes using Markers" Mathieu -- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From mboxrd@z Thu Jan 1 00:00:00 1970 From: compudj@krystal.dyndns.org (Mathieu Desnoyers) Date: Wed, 3 Dec 2008 00:26:40 -0500 Subject: [ltt-dev] trace a futex In-Reply-To: <4935B25F.7010701@web.de> References: <8d94e9280812021142j2eb5ca72td730410e97ccd9a1@mail.gmail.com> <20081202195015.GA25792@Krystal> <8d94e9280812021215m6a63d6c2l4e64acd26274953d@mail.gmail.com> <20081202215519.GA734@Krystal> <4935B25F.7010701@web.de> Message-ID: <20081203052640.GA13701@Krystal> Message-ID: <20081203052640.WxaeF2F0Pfg0PksH0QsM3TwqUojjieyTqSpHtap0eRM@z> * Jan Kiszka (jan.kiszka at web.de) wrote: > 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 > It still isn't instrumented, and I think it would be good to add such instrumentation. Have a look at the patch done by K. Prasad for futex.c : it should probably be updated so it uses tracepoints instead of markers. Anyone would like to do this ? See http://lkml.org/lkml/2008/4/15/125 "[RFC PATCH 0/2] Debugging infrastructure for Futexes using Markers" Mathieu -- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: