
<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div>Hi Yonghong,<br></div><div><br data-mce-bogus="1"></div><div><span id="zwchr" data-marker="__DIVIDER__">----- On Dec 19, 2018, at 1:19 PM, Yonghong Yan <yanyh15@gmail.com> wrote:<br></span></div><div data-marker="__QUOTED_TEXT__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="ltr"><div dir="ltr">We are experimenting LTTng for tracing multi-threaded program, it works very well for us. Thank you for having this great tool. But we have some concerns about the overhead and scalability of the tracing. Could you share some insight of the following questions?</div><div dir="ltr"><div>1. The session domain communicates with the user application via Unix domain socket, from LTTng document. is the communication frequent, such as each event requires communication, or the communication just happens at the beginning to configure user space tracing?</div></div></div></blockquote><div>This Unix socket is only for "control" of tracing (infrequent communication). The high-throughput tracing data goes through a shared memory map (per-cpu buffers).<br></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="ltr"><div dir="ltr"><div>2. For the consumer domain, is the consumer domain has a thread per CPU/channel to write to disk or relay the traces, or it is a single threaded-process handling all the channels and ring buffers, which could become a bottleneck if we have large number of user threads all feeding traces?</div></div></div></blockquote><div>Each consumer daemon is a single thread at the moment. It could be improved by implementing a multithreaded design in the future. It should help especially in NUMA setups, where having the consumer daemon on the same NUMA node as the ring buffer it reads from would minimize the amount of remote NUMA accesses.<br></div><div><br data-mce-bogus="1"></div><div>Another point is cases where I/O is performed to various target locations (different network interfaces or disks). When all I/O goes through the same interface, the bottleneck becomes the block device or the network interface. However, for scenarios involving many network interfaces or block devices, then multithreading the consumer daemon could become useful.</div><div><br data-mce-bogus="1"></div><div>This has not been a priority for anyone so far though.<br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="ltr"><div dir="ltr"><div>3. In the one channel/ring buffer per CPU setting, if a user thread migrates from one CPU to another, are the traces generated by that user thread fed to the two channels/buffers for the two CPUs?</div></div></div></blockquote><div>The event generated will belong to the per-cpu buffer on which the "sched_getcpu()" invocation occurs for the event. It is only saved into a single per-cpu buffer, even if the thread is migrated to a different CPU before it completes writing the event. This effectively creates infrequent situations where threads write into other cpu's per-cpu buffers. Note that the "reserve" and "commit" operations are smp-safe in lttng-ust for that reason.</div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="ltr"><div dir="ltr"><div>4. So far, the events for tracing can be enabled and disabled from command line, are you considering to have runtime options (APIs) to enable or disable certain events? Or this is the feature that already in or can be implemented in different way?</div></div></div></blockquote><div>We already expose a public LGPLv2.1 API for this. See lttng-tools:<br></div><div><br data-mce-bogus="1"></div><div>include/lttng/event.h: lttng_enable_event()<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>It is implemented by liblttng-ctl.so<br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="ltr"><div dir="ltr"><div>5. For context field, from the document, context fields cannot be removed from a channel once you add it. I would like to request a feature to allow removing context fields in the user program. </div></div></div></blockquote><div>That's unfortunately not that simple. The channel context field belongs to the channel, which maps to the "stream" description in the resulting CTF metadata in the output trace. That stream description is invariant once it has been created.<br></div><div><br data-mce-bogus="1"></div><div>So currently the only way to remove a context would be to destroy your tracing session and create a new one.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Thanks for your interest in LTTng!<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Mathieu<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="ltr"><div dir="ltr"><br><div>Thank you very much.</div><div>Yonghong</div><br><br></div></div>

<br>_______________________________________________<br>lttng-dev mailing list<br>lttng-dev@lists.lttng.org<br>https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev<br></blockquote></div><div><br></div><div data-marker="__SIG_POST__">-- <br></div><div>Mathieu Desnoyers<br>EfficiOS Inc.<br>http://www.efficios.com</div></div></body></html>