Messages in this thread | | | Subject | Re: [PATCH 10/11] tracing/perf: Fix lock events recursions in the fast path | From | Peter Zijlstra <> | Date | Fri, 05 Feb 2010 13:12:53 +0100 |
| |
On Fri, 2010-02-05 at 13:10 +0100, Peter Zijlstra wrote: > On Fri, 2010-02-05 at 11:49 +0100, Ingo Molnar wrote: > > > > > That said, I'm not at all happy about removing lockdep annotations to make > > > the tracer faster, that's really counter productive. > > > > Are there no dynamic techniques that could be used here? > > > > Lockdep obviously wants maximum instrumentation coverage - performance be > > damned. > > > > Lock profiling/tracing/visualization wants the minimum subset of events it is > > interested in - everything else is unnecessary overhead. > > Well, they could start by moving the tracepoint inside the lockdep > recursion check.
IIRC the reason its now outside is that you'd loose tracepoint on lockdep_off() usage, but having the tracer folks help on removing any such usage is of course a good thing.
The usage thereof in nmi_enter() doesn't seem like a problem, since you're not supposed to be using locks from nmi context anyway, more so, I'd not be adverse to putting BUG_ON(in_nmi()) in every lockdep hook.
| |