[lttng-dev] tracing multithread user program and API support for enabling/disabling events and for adding/removing context fields

[Mathieu Desnoyers]

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 <yanyh15 at 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.desnoyers at efficios.com | mathieu.desnoyers at efficios.com ] >
> wrote:

>> ----- On Dec 19, 2018, at 5:07 PM, Yonghong Yan < [ mailto:yanyh15 at gmail.com |
>> yanyh15 at gmail.com ] > wrote:

>>> Mathieu,

>>> Thank you for your response. see inline ...

>>> On Wed, Dec 19, 2018 at 4:20 PM Mathieu Desnoyers < [
>>> mailto:mathieu.desnoyers at efficios.com | mathieu.desnoyers at 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 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20181220/92da24e5/attachment.html>