lkml.org 
[lkml]   [2008]   [Aug]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Efficient x86 and x86_64 NOP microbenchmarks
    * Andi Kleen (andi@firstfloor.org) wrote:
    > > So microbenchmarking this way will probably make some things look
    > > unrealistically good.
    >
    > Must be careful to miss the big picture here.
    >
    > We have two assumptions here in this thread:
    >
    > - Normal alternative() nops are relatively infrequent, typically
    > in points with enough pipeline bubbles anyways, and it likely doesn't
    > matter how they are encode. And also they don't have an issue
    > with mult part instructions anyways because they're not patched
    > at runtime, so always the best known can be used.
    >
    > - The one case where nops are very frequent and matter and multipart
    > is a problem is with ftrace noping out the call to mcount at runtime
    > because that happens on every function entry.
    > Even there the overhead is not that big, but at least measurable
    > in kernel builds.
    >
    > Now the numbers have shown that just by not using frame pointer (
    > -pg right now implies frame pointer) you can get more benefit
    > than what you lose from using non optimal nops.
    >
    > So for me the best strategy would be to get rid of the frame pointer
    > and ignore the nops. This unfortunately would require going away
    > from -pg and instead post process gcc output to insert "call mcount"
    > manually. But the nice advantage of that is that you could actually
    > set up a custom table of callers built in a ELF section and with
    > that you don't actually need the runtime patching (which is only
    > done currently because there's no global table of mcount calls),
    > but could do everything in stop_machine(). Without
    > runtime patching you also don't need single part nops.
    >

    I agree that if frame pointer brings a too big overhead, it should not
    be used.

    Sorry to ask, I feel I must be missing something, but I'm trying to
    figure out where you propose to add the "call mcount" ? In the caller or
    in the callee ?

    In the caller, I guess it would replace the normal function call, call a
    trampoline which would jump to the normal code.

    In the callee, as what is currently done with -pg, the callee would have
    a call mcount at the beginning of the function.

    Or is it a different scheme I don't see ? I am trying to figure out how
    you happen to do all that without dynamic code modification and manage
    not to hurt performance.

    Mathieu

    > I think that would be the best option. I especially like it because
    > it would prevent forcing frame pointer which seems to be costlier
    > than any kinds of nosp.
    >
    > -Andi
    >

    --
    Mathieu Desnoyers
    OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68


    \
     
     \ /
      Last update: 2008-08-13 21:33    [W:2.100 / U:0.408 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site