Messages in this thread | | | Date | Fri, 19 Mar 2010 02:23:41 +0100 | From | Frederic Weisbecker <> | Subject | Re: [PATCH RFC 00/11] lock monitor: Separate features related to lock |
| |
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!
| |