lkml.org 
[lkml]   [2008]   [Jan]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 2/2] Markers Implementation for Preempt RCU Boost Tracing
    From
    Date
    Ingo Molnar <mingo@elte.hu> writes:

    > [...] Firstly, why on earth does a full format string have to be
    > passed in for something as simple as a CPU id? This way we basically
    > codify it forever that tracing _has_ to be expensive when
    > enabled. [...]

    FWIW, I'm not keen about the format strings either, but they don't
    constitute a performance hit beyond an additional parameter. It does
    not need to actually get parsed at run time.


    >[...]
    > Secondly, the inlined overhead of trace_mark() is still WAY too large:
    >
    > if (unlikely(__mark_##name.state)) { \
    > [...]
    > } \

    Note that this is for the unoptimized case. The immediate-value code
    is better. I have still yet to see some good measurements of how much
    the overheads of the various variants are, however. It's only fair to
    gather these numbers and continue the debate with them in hand.


    > Whatever became of the obvious suggestion that i outlined years ago,
    > to have a _single_ trace call instruction and to _patch out_ the
    > damn marker calls by default? [...] only leaving a ~5-byte NOP
    > sequence behind them (and some minimal disturbance to the variables
    > the tracepoint accesses). [...]

    This has been answered several times before. It's because the marker
    parameters have to be (conditionally) evaluated and pushed onto a call
    frame. It's not just a call that would need being nop'd, but a whole
    function call setup/teardown sequence, which itself can be interleaved
    with adjacent code.


    - FChE


    \
     
     \ /
      Last update: 2008-01-02 05:31    [W:5.057 / U:0.064 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site