From: francis.giraldeau@gmail.com (Francis Giraldeau)
Subject: [lttng-dev] notrace missing in lttng-ust
Date: Mon, 01 Oct 2012 00:06:01 -0400 [thread overview]
Message-ID: <506916A9.2050308@gmail.com> (raw)
In-Reply-To: <20120717141301.GA21204@Krystal>
Le 2012-07-17 10:13, Mathieu Desnoyers a ?crit :
> * Woegerer, Paul (Paul_Woegerer at mentor.com) wrote:
>> Hi Mathieu,
>>
>> here is the revised patch that makes tracepoint.h and
>> ust-tracepoint-event.h robust against -finstrument-functions.
>
> I think we want to make the notrace always active. I don't see the point
> in letting UST lib be compiled with those tracing stubs in place.
I just hit a case where it would have been useful to profile lttng-ust
itself.
When generating events in a tight loop, the average time to execute a
simple tracepoint is about 280ns on my machine. But the problem is that
once in a while (once out of a million execution) the latency bump to a
blazing 100us. I agree, it's still fast, but nonetheless the maximum is
~350 times more than the average, which is strange.
I tried many profiling tools (perf, valgrind, etc.) and none was
providing good results. It's no point to use lttng-ust itself (are
tracepoints reentrants?). So, I decided to try -finstrument-functions
stuff with a small pre-allocated ringbuffer to get the lowest latency
possible. Well, it turns out that I was getting no results for the
tracepoint, because function instrumentation is disabled.
I tried to re-enable it, but then the instrumented app fails with this
error message:
/usr/local/include/lttng/ust-tracepoint-event.h:646:
__lttng_events_init__npt: Assertion `!ret' failed.
I confess that I didn't look deeply into this problem, but it's quite
strange that the init fails in the case function instrumentation is
enabled. Could it be related to the dlopen() done at registration? Maybe
somebody has an idea, because I saw screenshots of similar profiling
previously on the ML ;) Here is the configuration options to lttng-ust
(the profiling library is miniprof[1]):
./configure CFLAGS="-finstrument-functions" LIBS="-lminiprof"
LDFLAGS="-L/usr/local/lib -Wl,-E"
Cheers,
Francis
[1] https://github.com/giraldeau/miniprof
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4489 bytes
Desc: Signature cryptographique S/MIME
URL: <http://lists.lttng.org/pipermail/lttng-dev/attachments/20121001/1e34e8dd/attachment.bin>
next prev parent reply other threads:[~2012-10-01 4:06 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-29 8:28 Woegerer, Paul
2012-06-30 18:16 ` Mathieu Desnoyers
[not found] ` <4FF2A31D.9020100@mentor.com>
[not found] ` <20120717141301.GA21204@Krystal>
2012-10-01 4:06 ` Francis Giraldeau [this message]
2012-10-01 15:29 ` Mathieu Desnoyers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=506916A9.2050308@gmail.com \
--to=francis.giraldeau@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox