From mboxrd@z Thu Jan  1 00:00:00 1970
From: compudj@krystal.dyndns.org (Mathieu Desnoyers)
Date: Fri, 5 Dec 2008 07:28:22 -0500
Subject: [ltt-dev] trace a futex
In-Reply-To: <1228380784.5092.18.camel@twins>
References: <8d94e9280812021142j2eb5ca72td730410e97ccd9a1@mail.gmail.com>
	<20081202195015.GA25792@Krystal>
	<8d94e9280812021215m6a63d6c2l4e64acd26274953d@mail.gmail.com>
	<20081202215519.GA734@Krystal> <4935B25F.7010701@web.de>
	<20081203052640.GA13701@Krystal> <20081203180131.GA2904@in.ibm.com>
	<1228380784.5092.18.camel@twins>
Message-ID: <20081205122822.GA25816@Krystal>

* Peter Zijlstra (peterz at infradead.org) wrote:
> 
> FWIW, the ftrace infrastructure has on many an occasion (even before it
> was called ftrace and specific to -rt) helped in debugging and fixing
> futex races.
> 

Hrm, I'm not sure futex races is the key aspect of interest here.
Knowing which amount of pthread mutex lock calls ends up calling the
scheduler looks a bit more like the topic brought by this particular
use-case. Therefore, correlating the information from the nptl with the
kernel information would be useful.

Is lockdep called when a futex is taken ? Should we add instrumentation
(tracepoints) to futex.c ? If yes, was there specific instrumentation
you used with ftrace that should be added ?

Mathieu

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68