All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: performance improvement, stop channel tracing, etc
       [not found] <CANgVouXut+oT0nddOXTd=GXSyysF+AU33wYVcG2eCALjx6MMMg@mail.gmail.com>
@ 2015-12-11 23:13 ` John Smith
  0 siblings, 0 replies; 2+ messages in thread
From: John Smith @ 2015-12-11 23:13 UTC (permalink / raw)
  To: lttng-dev


[-- Attachment #1.1: Type: text/plain, Size: 1765 bytes --]

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@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
>

[-- Attachment #1.2: Type: text/html, Size: 2355 bytes --]

[-- Attachment #2: Type: text/plain, Size: 155 bytes --]

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

^ permalink raw reply	[flat|nested] 2+ messages in thread

* performance improvement, stop channel tracing, etc
@ 2015-12-11  4:44 John Smith
  0 siblings, 0 replies; 2+ messages in thread
From: John Smith @ 2015-12-11  4:44 UTC (permalink / raw)
  To: lttng-dev


[-- Attachment #1.1: Type: text/plain, Size: 1151 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 1379 bytes --]

[-- Attachment #2: Type: text/plain, Size: 155 bytes --]

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2015-12-11 23:13 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <CANgVouXut+oT0nddOXTd=GXSyysF+AU33wYVcG2eCALjx6MMMg@mail.gmail.com>
2015-12-11 23:13 ` performance improvement, stop channel tracing, etc John Smith
2015-12-11  4:44 John Smith

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.