[lkml]   [2010]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [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.



     \ /
      Last update: 2010-03-19 02:25    [W:4.688 / U:0.028 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site