Messages in this thread | | | Date | Wed, 10 Feb 2010 11:17:07 +0100 | From | Frederic Weisbecker <> | Subject | Re: [PATCH 10/11] tracing/perf: Fix lock events recursions in the fast path |
| |
On Sun, Feb 07, 2010 at 10:45:55AM +0100, Peter Zijlstra wrote: > On Sat, 2010-02-06 at 17:10 +0100, Frederic Weisbecker wrote: > > > > > > Looks pretty what I'm looking for. Except that it still continues > > > > to fill and keep track of the locks held by the current thread, > > > > namely the copies in curr->held_locks. > > > > > > Which is exactly what you need for that lock hierarchy recording you > > > wanted :-) > > > > > > Well, the lock hierarchy should probably be retrieved from the traces, > > using state machines. > > Otherwise we would need yet other lock events for that, which is going > > to add even more overhead. > > > Right, well you could look at adding a mode that also strips out the > held_lock tracing, but since you really need the register class stuff to > re-generate the class mapping, avoiding the held_lock tracing doesn't > look like it's going to save you much, its all thread local storage.
But if we draw a tree based representation (per-instances or per-class) from perf lock, we'll already need to get the locking scenarios from post processing, which induce the dependencies.
I don't think it will help much.
Thanks.
| |