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

[Yonghong Yan]

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

>
> ----- On Dec 19, 2018, at 5:07 PM, Yonghong Yan <yanyh15 at gmail.com> wrote:
>
> Mathieu,
>
> Thank you for your response. see inline ...
>
> On Wed, Dec 19, 2018 at 4:20 PM Mathieu Desnoyers <
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20181220/cda00dc3/attachment-0001.html>