If you want to follow the activity of a given thread, you would need to enable the "vtid" context with "lttng add-context -u -t vtid". Then, you will be able to follow the activity of each thread even though the events are recorded into per-cpu buffers.
Cheers! Mathieu ----- On Dec 20, 2018, at 2:59 PM, Yonghong Yan <yany...@gmail.com> wrote: > 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 < [ > mailto:mathieu.desnoy...@efficios.com | mathieu.desnoy...@efficios.com ] > > wrote: >> ----- On Dec 19, 2018, at 5:07 PM, Yonghong Yan < [ mailto:yany...@gmail.com >> | >> yany...@gmail.com ] > wrote: >>> Mathieu, >>> Thank you for your response. see inline ... >>> On Wed, Dec 19, 2018 at 4:20 PM Mathieu Desnoyers < [ >>> mailto:mathieu.desnoy...@efficios.com | 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/ | http://www.efficios.com ] -- 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
