Re: [PATCH RFC 00/11] lock monitor: Separate features related to lock

[Frederic Weisbecker <fweisbec@gmail.com>]

On Thu, Mar 18, 2010 at 09:08:57PM -0400, Mathieu Desnoyers wrote:
> > 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,
> 
> yep, tracepoints with jump patching will branch over the whole stack setup in
> the off case, which is one of the good reasons for using this solution over
> patching only a call (leaving the stack setup in place).



Ok that's good to know. It's a pretty good argument against hot
patching in this particular case.


 
> Note that if the parameters include side-effects (such as a function call),
> these will be executed even when the tracepoint is disabled. This is why people
> should implement these calls with side-effects in the appropriate TRACE_EVENT
> fields.


Good to know too.
But this makes me curious. So it guarantees stack setup won't happen but
can't sort it out with functions as parameters or so?

I have no idea how this thing works. Please Cc me for the next batch,
this looks like a cool thing :)



> > 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)
> > 
> 
> The idea has been discussed to add support in gcc to emit the code for an
> unlikely branch into a separate section, which does have the smaller cache-line
> footprint benefit your are talking about, but without the overhead of the extra
> out-of-line function call in the enabled case. I don't know how this work is
> advanced though. We had determined that the "asm goto" was an higher priority
> item.


Ok.

Thanks!