[lttng-dev] performance improvement, stop channel tracing, etc

John Smith whalajam at gmail.com
Fri Dec 11 18:13:08 EST 2015

Forgot few more:

5) CPU and hostname are by default part of the channel context, is it any
way to remove them from the output? there are options to add context but
how do we remove the ones the are there by default?

6) "lttng view": we need to look at session files that have been moved from
its initial location (that was at trace capture time), is it a way to
achieve that?
Also, we'd like to "view" traces per channel based and not the whole
session, is it a way to do so?

thanks, John

On Thu, Dec 10, 2015 at 8:44 PM, John Smith <whalajam at gmail.com> wrote:

> Hi,
> I have a couple of questions, here they are:
> 1) tracing latency, on a simple loop tracing test I noticed the latency is
> around 400ns on a 3.2GHz processor, are there ways to reduce this latency?
> One thought about RCU, it is an efficient mechanism for multiple writers
> but when there is a single source for the events, it may not be
> necessary, my understanding is that the trace collection/read is done when
> the sub-buffer is not been populated/written.
> 2) I noticed the log [delta] interval (2-nd value) is not actually the
> difference between the two sequential traces (of the same event)
> timestamps, did I miss anything and it represents something else or is a
> bug?
> 3) Is there an api available to stop a channel tracing while session has
> started ("lttng start") and of course before it has ended ("lttng stop")?
> That would be useful if we want to stop tracing in case of critical events.
> 4) it would be useful if the tracepoint() (I know is a macro now) would
> return some information about the success, overwrite or discard (depending
> on the channel configuration) of the event, is it a way to get this
> information currently?
> thanks, John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lttng.org/pipermail/lttng-dev/attachments/20151211/8c4432c7/attachment.html>

More information about the lttng-dev mailing list