Thank you Mathieu. I agree that my question is not precise, but I got what I need from your answer. I wanted to know that when a user thread migrates, the ring buffer the events go to will change. This is not what we want, but i understand why LTTng does that way since it needs to trace the activities on each CPU.
On Thu, Dec 20, 2018 at 12:56 PM Mathieu Desnoyers < mathieu.desnoy...@efficios.com> wrote: > > ----- On Dec 19, 2018, at 5:07 PM, Yonghong Yan <yany...@gmail.com> wrote: > > Mathieu, > > Thank you for your response. see inline ... > > On Wed, Dec 19, 2018 at 4:20 PM Mathieu Desnoyers < > mathieu.desnoy...@efficios.com> wrote: > > [...] > > > 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? >> >> 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. >> > > so after the migration, new events will still be written to another CPU's > buffer? > > > 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. > > 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. > > 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. > > [...] > > 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. >> >> 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. >> > That makes senses. > > 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. > > 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). > > Thanks, > > Mathieu > > > -- > Mathieu Desnoyers > EfficiOS Inc. > http://www.efficios.com >
_______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
