[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1228492692.20520.3.camel@twins>
Date: Fri, 05 Dec 2008 16:58:12 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Mathieu Desnoyers <compudj@...stal.dyndns.org>
Cc: prasad@...ux.vnet.ibm.com, jan.kiszka@....de,
Gian Lorenzo Meocci <glmeocci@...il.com>,
ltt-dev@...ts.casi.polymtl.ca, linux-kernel@...r.kernel.org,
mbligh@...gle.com, tglx.de@...ns.programming.kicks-ass.net
Subject: Re: [ltt-dev] trace a futex
On Fri, 2008-12-05 at 07:28 -0500, Mathieu Desnoyers wrote:
> * Peter Zijlstra (peterz@...radead.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.
We already have the scheduler instrucmentation, so correlating that to
known futex calls (from userspace) shouldn't be too hard.
> Is lockdep called when a futex is taken ?
lockdep only does kernel-internal locks - so no.
> Should we add instrumentation
> (tracepoints) to futex.c ? If yes, was there specific instrumentation
> you used with ftrace that should be added ?
Not sure we should, Thomas did the bulk of that ftrace debugging, Thomas
do you think it would be worthwhile to add some tracepoints in there?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists