[lttng-dev] efficient use of LTTng in legacy codebase
Mathieu Desnoyers
mathieu.desnoyers at efficios.com
Wed Dec 11 19:47:31 EST 2013
----- Original Message -----
> From: "Máté Ferenczy" <mate.ferenczy at ericsson.com>
> To: "mathieu desnoyers" <mathieu.desnoyers at efficios.com>
> Cc: lttng-dev at lists.lttng.org
> Sent: Wednesday, December 11, 2013 6:52:22 PM
> Subject: RE: efficient use of LTTng in legacy codebase
> I found this email thread:
> https://www.mail-archive.com/lttng-dev@lists.lttng.org/msg02278.html
> According to this I could just check
> caa_unlikely(__tracepoint_##provider##___##name.state). However, Dave claims
> that this state will stay true even if the tracepoint is disabled. Is there
> anything else I should check for?
I would recommend doing this in the UST probe provider instead. Within the TRACEPOINT_EVENT "TP_FIELD" section, when you declare your string field, you could parse the format string there in the last argument of a ctf_string() (a statement expression). The format string would be received as parameter by the tracepoint, along with a variable arg list (...). In the probe, it would be turned into a va_list (see stdarg(3)), and the parameters could be decoded into a string there. This has the benefit of moving the serialization call out-of-line into the probe provider rather than clobbering the tracepoint call site.
Thoughts ?
Thanks,
Mathieu
> Thanks,
> Mate
> From: Máté Ferenczy
> Sent: Wednesday, December 11, 2013 12:17 PM
> To: 'mathieu.desnoyers at efficios.com'
> Cc: 'lttng-dev at lists.lttng.org'
> Subject: efficient use of LTTng in legacy codebase
> Hello Mathieu,
> Our team was asked to support LTTng UST solution in a legacy codebase. The
> existing codebase is fairly large, and the requirement is that we provide
> all the existing logs and debugs in the system as LTTng traces.
> The planned solution so far was just to pass everything we have as text
> (strings) to LTTng. For that we obviously have to convert the printf-like
> format string and parameter list to a string by calling snprintf before
> giving the string to the LTTng API. That would however mean, that these
> snprintfs are getting called every time even if there is no listener/active
> trace session for the given trace. In this case, all those unnecessary
> snprintf calls may end up significantly impacting the performance of our
> applications.
> In order to work around this, we were thinking that if there was a way to
> query the LTTng library from our application code whether there is an active
> tracing session for the given trace level, we could avoid calling those
> snprintfs in case they are not needed. Do you think it would be feasible to
> easily get this data from LTTng lib? If yes, can you provide us some
> pointers where to look at in order to do those changes ourselves?
> Any suggestions are welcome.
> Thank you,
> Mate Ferenczy
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lttng.org/pipermail/lttng-dev/attachments/20131212/03fed7e8/attachment.html>
More information about the lttng-dev
mailing list