<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div><br data-mce-bogus="1"></div><div><span id="zwchr" data-marker="__DIVIDER__">----- On Dec 19, 2018, at 5:07 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">Mathieu, <div><br>Thank you for your response. see inline ...</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Dec 19, 2018 at 4:20 PM Mathieu Desnoyers <<a href="mailto:mathieu.desnoyers@efficios.com" target="_blank">mathieu.desnoyers@efficios.com</a>> wrote:<br></div></div></div></blockquote>[...]<div><br></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 class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:arial,helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"><div><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);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></div></div></div></blockquote><br><div>so after the migration, new events will still be written to another CPU's buffer? </div></div></div></blockquote><div><br data-mce-bogus="1"></div><div>After migration of a thread, the value returned by following calls to sched_getcpu() will match the target processor onto which the thread is migrated. Therefore, "new events" will be written into the buffers belonging to the CPU onto which the thread has been migrated.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>I'm not sure I fully understand your question though, as the concept of "another CPU's buffer" related to a migrated thread can technically mean the CPU that is either the source or the target of the migration. The wording of the question is therefore imprecise.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>The infrequent cases where events are written into other CPU's buffers is only if migration happens between invocation of sched_getcpu() by lttng-ust and the associated commit of an event.<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 class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:arial,helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"><div><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);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></div></div></blockquote><div>That makes senses. </div><br><div>We use babeltrace to process trace records. So far, it presents a single-ordered event sequence and we have to use a dedicated event record filed to separate the traces what are from different channels/threads. Is there library or API (C or python-based) that allows us to process traces channel by channel? I saw the traces are saved in files of channels. </div></div></div></blockquote><div>Not that I know of, but it would make a good feature request for a babeltrace 2 plugin, either as a filter plugin, or as an extension to the CTF source plugin (not sure what would be the best approach design-wise, I would have to defer to Philippe and Jeremie on this topic).<br></div><div><br data-mce-bogus="1"></div><div>Thanks,<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><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>