----- Original Message ----- > From: "Máté Ferenczy" <[email protected]> > To: "mathieu desnoyers" <[email protected]> > Cc: [email protected] > 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/[email protected]/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: '[email protected]' > Cc: '[email protected]' > 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
_______________________________________________ lttng-dev mailing list [email protected] http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
