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

[Mathieu Desnoyers]

----- 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 < [
> 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 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20181220/36a07152/attachment.html>