Re: [PATCH 2/2] Markers Implementation for Preempt RCU Boost Tracing

[Frank Ch. Eigler]

Ingo Molnar <mingo@xxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/