lkml.org 
[lkml]   [2010]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH RFC 00/11] lock monitor: Separate features related to lock
On Thu, Mar 18, 2010 at 02:59:29PM +0900, Hitoshi Mitake wrote:
> 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!



I sometimes wonder which trick between jmp optimization and hot patching
would be the best to optimize the tracepoints off-cases.

I should look more closely at the jmp optimization. I don't know if
it avoids to push the tracepoints parameters in the off case, in
which case it could be perhaps more efficient than hot patching,
although perhaps most of the time the given arguments are already in
registers because the traced function uses them for its own needs.

Also, adopting hot patching means the tracepoint calls would be
in a non-inlined separated function. The result would be probably
less i-cache footprint from the caller, and better for the off-case,
worse for the on-case. But tracing off-case is most important.

(Adding more people in Cc)


> 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?


There is almost always a process with a lock somewhere ;-)

This is not a big deal, it's very similar to unfinished scenarios
due to the end of the tracing that can happen anytime and you miss
a lock_release or whatever. We can also begin the tracing anytime,
and you may receive orphan lock_release in the very beginning
because you missed the lock_acquire that happened before the tracing.

Any locking scenario that doesn't fit into the state machine
or is incomplete must be considered as broken and then ignored.



\
 
 \ /
  Last update: 2010-03-18 22:19    [W:0.077 / U:0.284 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site