Messages in this thread | | | Date | Thu, 18 Mar 2010 14:59:29 +0900 | From | Hitoshi Mitake <> | Subject | Re: [PATCH RFC 00/11] lock monitor: Separate features related to lock |
| |
On 03/17/10 18:52, Ingo Molnar wrote: > > * Frederic Weisbecker<fweisbec@gmail.com> wrote: > >>> You add chained indirect calls into all lock ops, that's got to hurt. >> >> Well, the idea was not bad at the first glance. It was separating lockdep >> and lock events codes. >> >> But indeed, the indirect calls plus the locking are not good for such a fast >> path. > > What would be nice to have is some sort of dynamic patching approach to enable > _both_ lockdep, lockstat and perf lock. > > If TRACE_EVENT() tracepoints were patchable we could use them. (but they arent > right now)
I'll try it!
And I have a question related to this dynamic patching approach for lockdep. If dynamic proving turning on/off is provided, lockdep will be confused by inconsistency of lock acquiring log.
Will the sequence,
lock_acquire(l) -> turning off -> lock_release(l) -> turning on -> lock_acquire(l)
detected as double acquiring?
Should turning on/off lockdep be done in the time when every processes have no lock?
| |