[lttng-dev] TP_ARGS for TRACEPOINT_EVENT_CLASS and TRACEPOINT_EVENT_INSTANCE

[Yonghong Yan]

I am looking at the following example from lttng-ust manual. The same
TP_ARGS ( ... ) are repeated in both the TRACEPOINT_EVENT_CLASS and
TRACEPOINT_EVENT_INSTANCE definition. My understanding is that it actually
allows using different arguments, even in this example it is the same. Am I
right?

I also like the feature of having one TP_ARGS in the TRACEPOINT_EVENT_CLASS
that declares the arguments for several TRACEPOINT_EVENT_INSTANCE so we do
not need to have TP_ARGS in TRACEPOINT_EVENT_INSTANCE. Is that possible?

Thank you
Yonghong

TRACEPOINT_EVENT_CLASS(
my_provider,
my_tracepoint_class,
TP_ARGS(
int, my_integer_arg,
struct app_struct *, app_struct_arg
),
TP_FIELDS(
ctf_integer(int, a, my_integer_arg)
ctf_integer(unsigned long, b, app_struct_arg->b)
ctf_string(c, app_struct_arg->c)
)
)

TRACEPOINT_EVENT_INSTANCE(
my_provider,
my_tracepoint_class,
event_instance1,
TP_ARGS(
int, my_integer_arg,
struct app_struct *, app_struct_arg
)
)

TRACEPOINT_EVENT_INSTANCE(
my_provider,
my_tracepoint_class,
event_instance2,
TP_ARGS(
int, my_integer_arg,
struct app_struct *, app_struct_arg
)
)
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: [lttng-dev] TP_ARGS for TRACEPOINT_EVENT_CLASS and TRACEPOINT_EVENT_INSTANCE

[Philippe Proulx]

On Thu, Dec 20, 2018 at 11:47 AM Yonghong Yan  wrote:
>
> I am looking at the following example from lttng-ust manual. The same TP_ARGS 
> ( ... ) are repeated in both the TRACEPOINT_EVENT_CLASS and 
> TRACEPOINT_EVENT_INSTANCE definition. My understanding is that it actually 
> allows using different arguments, even in this example it is the same. Am I 
> right?

No it does not: they need to match.

See 
.

Phil

>
> I also like the feature of having one TP_ARGS in the TRACEPOINT_EVENT_CLASS 
> that declares the arguments for several TRACEPOINT_EVENT_INSTANCE so we do 
> not need to have TP_ARGS in TRACEPOINT_EVENT_INSTANCE. Is that possible?
>
> Thank you
> Yonghong
>
> TRACEPOINT_EVENT_CLASS(
> my_provider,
> my_tracepoint_class,
> TP_ARGS(
> int, my_integer_arg,
> struct app_struct *, app_struct_arg
> ),
> TP_FIELDS(
> ctf_integer(int, a, my_integer_arg)
> ctf_integer(unsigned long, b, app_struct_arg->b)
> ctf_string(c, app_struct_arg->c)
> )
> )
>
> TRACEPOINT_EVENT_INSTANCE(
> my_provider,
> my_tracepoint_class,
> event_instance1,
> TP_ARGS(
> int, my_integer_arg,
> struct app_struct *, app_struct_arg
> )
> )
>
> TRACEPOINT_EVENT_INSTANCE(
> my_provider,
> my_tracepoint_class,
> event_instance2,
> TP_ARGS(
> int, my_integer_arg,
> struct app_struct *, app_struct_arg
> )
> )
>
>
> ___
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: [lttng-dev] TP_ARGS for TRACEPOINT_EVENT_CLASS and TRACEPOINT_EVENT_INSTANCE

[Yonghong Yan]

Then why bother to require to have the TP_ARGS in
TRACEPOINT_EVENT_INSTANCE?

Yonghong

On Thu, Dec 20, 2018 at 11:56 AM Philippe Proulx 
wrote:

> On Thu, Dec 20, 2018 at 11:47 AM Yonghong Yan  wrote:
> >
> > I am looking at the following example from lttng-ust manual. The same
> TP_ARGS ( ... ) are repeated in both the TRACEPOINT_EVENT_CLASS and
> TRACEPOINT_EVENT_INSTANCE definition. My understanding is that it actually
> allows using different arguments, even in this example it is the same. Am I
> right?
>
> No it does not: they need to match.
>
> See <
> https://github.com/lttng/lttng-ust/commit/c75c0422c64f33c0102e1778cecc812c58b700e5
> >.
>
> Phil
>
> >
> > I also like the feature of having one TP_ARGS in the
> TRACEPOINT_EVENT_CLASS that declares the arguments for several
> TRACEPOINT_EVENT_INSTANCE so we do not need to have TP_ARGS in
> TRACEPOINT_EVENT_INSTANCE. Is that possible?
> >
> > Thank you
> > Yonghong
> >
> > TRACEPOINT_EVENT_CLASS(
> > my_provider,
> > my_tracepoint_class,
> > TP_ARGS(
> > int, my_integer_arg,
> > struct app_struct *, app_struct_arg
> > ),
> > TP_FIELDS(
> > ctf_integer(int, a, my_integer_arg)
> > ctf_integer(unsigned long, b, app_struct_arg->b)
> > ctf_string(c, app_struct_arg->c)
> > )
> > )
> >
> > TRACEPOINT_EVENT_INSTANCE(
> > my_provider,
> > my_tracepoint_class,
> > event_instance1,
> > TP_ARGS(
> > int, my_integer_arg,
> > struct app_struct *, app_struct_arg
> > )
> > )
> >
> > TRACEPOINT_EVENT_INSTANCE(
> > my_provider,
> > my_tracepoint_class,
> > event_instance2,
> > TP_ARGS(
> > int, my_integer_arg,
> > struct app_struct *, app_struct_arg
> > )
> > )
> >
> >
> > ___
> > lttng-dev mailing list
> > lttng-dev@lists.lttng.org
> > https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
>
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: [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  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 
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: [lttng-dev] TP_ARGS for TRACEPOINT_EVENT_CLASS and TRACEPOINT_EVENT_INSTANCE

[Mathieu Desnoyers]

This is due to limitations of the C preprocessor. We need to have the TP_ARGS() 
available 
both in the TRACEPOINT_EVENT_INSTANCE(), which generates the tracepoint 
prototype 
used to validate type compability of the tracepoint callsite within the 
application, and within 
TRACEPOINT_EVENT_CLASS() which is used to generate the probe callback with the 
correct arguments. 

Unfortunately, the C preprocessor does not allow much freedom when it comes to 
accessing 
arguments of another macro. 

Thanks, 

Mathieu 

- On Dec 20, 2018, at 12:21 PM, Yonghong Yan  wrote: 

> Then why bother to require to have the TP_ARGS in TRACEPOINT_EVENT_INSTANCE?

> Yonghong

> On Thu, Dec 20, 2018 at 11:56 AM Philippe Proulx < [
> mailto:eeppelitel...@gmail.com | eeppelitel...@gmail.com ] > wrote:

>> On Thu, Dec 20, 2018 at 11:47 AM Yonghong Yan < [ mailto:yany...@gmail.com |
>> yany...@gmail.com ] > wrote:

>>> I am looking at the following example from lttng-ust manual. The same 
>>> TP_ARGS (
>>> ... ) are repeated in both the TRACEPOINT_EVENT_CLASS and
>>> TRACEPOINT_EVENT_INSTANCE definition. My understanding is that it actually
>>> allows using different arguments, even in this example it is the same. Am I
>> > right?

>> No it does not: they need to match.

>> See < [
>> https://github.com/lttng/lttng-ust/commit/c75c0422c64f33c0102e1778cecc812c58b700e5
>> |
>> https://github.com/lttng/lttng-ust/commit/c75c0422c64f33c0102e1778cecc812c58b700e5
>> ] >.

>> Phil


>>> I also like the feature of having one TP_ARGS in the TRACEPOINT_EVENT_CLASS 
>>> that
>>> declares the arguments for several TRACEPOINT_EVENT_INSTANCE so we do not 
>>> need
>> > to have TP_ARGS in TRACEPOINT_EVENT_INSTANCE. Is that possible?

>> > Thank you
>> > Yonghong

>> > TRACEPOINT_EVENT_CLASS(
>> > my_provider,
>> > my_tracepoint_class,
>> > TP_ARGS(
>> > int, my_integer_arg,
>> > struct app_struct *, app_struct_arg
>> > ),
>> > TP_FIELDS(
>> > ctf_integer(int, a, my_integer_arg)
>> > ctf_integer(unsigned long, b, app_struct_arg->b)
>> > ctf_string(c, app_struct_arg->c)
>> > )
>> > )

>> > TRACEPOINT_EVENT_INSTANCE(
>> > my_provider,
>> > my_tracepoint_class,
>> > event_instance1,
>> > TP_ARGS(
>> > int, my_integer_arg,
>> > struct app_struct *, app_struct_arg
>> > )
>> > )

>> > TRACEPOINT_EVENT_INSTANCE(
>> > my_provider,
>> > my_tracepoint_class,
>> > event_instance2,
>> > TP_ARGS(
>> > int, my_integer_arg,
>> > struct app_struct *, app_struct_arg
>> > )
>> > )


>> > ___
>> > lttng-dev mailing list
>> > [ mailto:lttng-dev@lists.lttng.org | lttng-dev@lists.lttng.org ]
>>> [ https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev |
>> > https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev ]

> ___
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

-- 
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

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

[Mathieu Desnoyers]

Hi, 

Can you define what you mean by "per-user-thread tracepoint" and 
"whole-user-process" ? AFAIK 
those concepts don't appear anywhere in the LTTng documentations. 

Thanks, 

Mathieu 

- On Dec 19, 2018, at 6:06 PM, Yonghong Yan  wrote: 

> Got another question about lttng_enable_event(): Using this API will impact
> per-user-thread tracepoint or the whole-user-process? I am thinking of the
> whole process, but want to confirm.

> Yonghong

> On Wed, Dec 19, 2018 at 4:20 PM Mathieu Desnoyers < [
> mailto:mathieu.desnoy...@efficios.com | mathieu.desnoy...@efficios.com ] >
> wrote:

>> Hi Yonghong,

>> - On Dec 19, 2018, at 1:19 PM, Yonghong Yan < [ mailto:yany...@gmail.com 
>> |
>> yany...@gmail.com ] > wrote:

>>> We are experimenting LTTng for tracing multi-threaded program, it works very
>>> well for us. Thank you for having this great tool. But we have some concerns
>>> about the overhead and scalability of the tracing. Could you share some 
>>> insight
>>> of the following questions?
>>> 1. The session domain communicates with the user application via Unix domain
>>> socket, from LTTng document. is the communication frequent, such as each 
>>> event
>>> requires communication, or the communication just happens at the beginning 
>>> to
>>> configure user space tracing?

>> This Unix socket is only for "control" of tracing (infrequent communication).
>> The high-throughput tracing data goes through a shared memory map (per-cpu
>> buffers).

>>> 2. For the consumer domain, is the consumer domain has a thread per 
>>> CPU/channel
>>> to write to disk or relay the traces, or it is a single threaded-process
>>> handling all the channels and ring buffers, which could become a bottleneck 
>>> if
>>> we have large number of user threads all feeding traces?

>> Each consumer daemon is a single thread at the moment. It could be improved 
>> by
>> implementing a multithreaded design in the future. It should help especially 
>> in
>> NUMA setups, where having the consumer daemon on the same NUMA node as the 
>> ring
>> buffer it reads from would minimize the amount of remote NUMA accesses.

>> Another point is cases where I/O is performed to various target locations
>> (different network interfaces or disks). When all I/O goes through the same
>> interface, the bottleneck becomes the block device or the network interface.
>> However, for scenarios involving many network interfaces or block devices, 
>> then
>> multithreading the consumer daemon could become useful.

>> This has not been a priority for anyone so far though.

>>> 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.

>>> 4. So far, the events for tracing can be enabled and disabled from command 
>>> line,
>>> are you considering to have runtime options (APIs) to enable or disable 
>>> certain
>>> events? Or this is the feature that already in or can be implemented in
>>> different way?

>> We already expose a public LGPLv2.1 API for this. See lttng-tools:

>> include/lttng/event.h: lttng_enable_event()

>> It is implemented by liblttng-ctl.so

>>> 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.

>> So currently the only way to remove a context would be to destroy your 
>> tracing
>> session and create a new one.

>> Thanks for your interest in LTTng!

>> Mathieu

>>> Thank you very much.
>>> Yonghong

>>> ___
>>> lttng-dev mailing list
>>> [ mailto:lttng-dev@lists.lttng.org | lttng-dev@lists.lttng.org ]
>>> [ https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev |
>>> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev ]

>> --
>> 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

Re: [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.desnoy...@efficios.com> wrote:

>
> - On Dec 19, 2018, at 5:07 PM, Yonghong Yan  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

Re: [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  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

[lttng-dev] [PATCH lttng-ust 1/4] Use a variable to select the dlopen lib in Makefiles

[Michael Jeanson]

Instead of multiple conditionnals, it makes for cleaner and more
readable Makefiles.

Signed-off-by: Michael Jeanson 
---
 configure.ac   |  8 +++-
 liblttng-ust-cyg-profile/Makefile.am   | 17 ++---
 liblttng-ust-dl/Makefile.am| 11 +++
 liblttng-ust-fd/Makefile.am| 11 +++
 liblttng-ust-fork/Makefile.am  | 10 ++
 liblttng-ust-libc-wrapper/Makefile.am  | 18 +++---
 liblttng-ust/Makefile.am   | 22 ++
 tests/benchmark/Makefile.am| 14 +++---
 tests/ctf-types/Makefile.am|  9 +
 tests/hello-many/Makefile.am   |  9 +
 tests/hello.cxx/Makefile.am|  9 +
 tests/hello/Makefile.am|  9 +
 tests/same_line_tracepoint/Makefile.am |  9 +
 tests/test-app-ctx/Makefile.am |  9 +
 tests/ust-variant/Makefile.am  |  9 +
 15 files changed, 40 insertions(+), 134 deletions(-)

diff --git a/configure.ac b/configure.ac
index 2ea15533..431ed21a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -207,17 +207,18 @@ AH_TEMPLATE([LTTNG_UST_HAVE_PERF_EVENT], [Perf event 
integration via perf_event.
 
 # Checks for libraries.
 AC_CHECK_LIB([dl], [dlopen], [
-   have_libdl=yes
libdl_name=dl
+   DL_LIBS="-ldl"
 ], [
#libdl not found, check for dlopen in libc.
AC_CHECK_LIB([c], [dlopen], [
-   have_libc_dl=yes
libdl_name=c
+   DL_LIBS="-lc"
], [
AC_MSG_ERROR([Cannot find dlopen in libdl nor libc. Use 
[LDFLAGS]=-Ldir to specify their location.])
])
 ])
+AC_SUBST(DL_LIBS)
 
 # Check if libdl has dlmopen support.
 AH_TEMPLATE([HAVE_DLMOPEN], ["Define to 1 if dlmopen is available."])
@@ -225,9 +226,6 @@ AC_CHECK_LIB([$libdl_name], [dlmopen],
[AC_DEFINE([HAVE_DLMOPEN], [1])]
 )
 
-AM_CONDITIONAL([LTTNG_UST_BUILD_WITH_LIBDL], [test "x$have_libdl" = "xyes"])
-AM_CONDITIONAL([LTTNG_UST_BUILD_WITH_LIBC_DL], [test "x$have_libc_dl" = 
"xyes"])
-
 AC_CHECK_LIB([pthread], [pthread_create])
 AC_CHECK_LIB([pthread], [pthread_setname_np],
AC_DEFINE([HAVE_PTHREAD_SETNAME_NP], [1], [Define to 1 if 
pthread_setname_np is available.]),
diff --git a/liblttng-ust-cyg-profile/Makefile.am 
b/liblttng-ust-cyg-profile/Makefile.am
index 3130282d..0ed2cd9c 100644
--- a/liblttng-ust-cyg-profile/Makefile.am
+++ b/liblttng-ust-cyg-profile/Makefile.am
@@ -7,25 +7,20 @@ lib_LTLIBRARIES = liblttng-ust-cyg-profile.la \
 liblttng_ust_cyg_profile_la_SOURCES = \
lttng-ust-cyg-profile.c \
lttng-ust-cyg-profile.h
+
 liblttng_ust_cyg_profile_la_LIBADD = \
-L$(top_builddir)/liblttng-ust/.libs \
-   -llttng-ust
+   -llttng-ust \
+   $(DL_LIBS)
 
 liblttng_ust_cyg_profile_fast_la_SOURCES = \
lttng-ust-cyg-profile-fast.c \
lttng-ust-cyg-profile-fast.h
+
 liblttng_ust_cyg_profile_fast_la_LIBADD = \
-L$(top_builddir)/liblttng-ust/.libs \
-   -llttng-ust
-
-if LTTNG_UST_BUILD_WITH_LIBDL
-liblttng_ust_cyg_profile_la_LIBADD += -ldl
-liblttng_ust_cyg_profile_fast_la_LIBADD += -ldl
-endif
-if LTTNG_UST_BUILD_WITH_LIBC_DL
-liblttng_ust_cyg_profile_la_LIBADD += -lc
-liblttng_ust_cyg_profile_fast_la_LIBADD += -lc
-endif
+   -llttng-ust \
+   $(DL_LIBS)
 
 noinst_SCRIPTS = run run-fast
 EXTRA_DIST = run run-fast
diff --git a/liblttng-ust-dl/Makefile.am b/liblttng-ust-dl/Makefile.am
index c0168f39..1f6d166a 100644
--- a/liblttng-ust-dl/Makefile.am
+++ b/liblttng-ust-dl/Makefile.am
@@ -6,14 +6,9 @@ liblttng_ust_dl_la_SOURCES = \
lttng-ust-dl.c \
ust_dl.c \
ust_dl.h
-liblttng_ust_dl_la_LIBADD = \
-   $(top_builddir)/liblttng-ust/liblttng-ust.la
 
-if LTTNG_UST_BUILD_WITH_LIBDL
-liblttng_ust_dl_la_LIBADD += -ldl
-endif
-if LTTNG_UST_BUILD_WITH_LIBC_DL
-liblttng_ust_dl_la_LIBADD += -lc
-endif
+liblttng_ust_dl_la_LIBADD = \
+   $(top_builddir)/liblttng-ust/liblttng-ust.la \
+   $(DL_LIBS)
 
 liblttng_ust_dl_la_CFLAGS = -DUST_COMPONENT=liblttng-ust-dl $(AM_CFLAGS)
diff --git a/liblttng-ust-fd/Makefile.am b/liblttng-ust-fd/Makefile.am
index f7706634..57122ec7 100644
--- a/liblttng-ust-fd/Makefile.am
+++ b/liblttng-ust-fd/Makefile.am
@@ -4,14 +4,9 @@ AM_CFLAGS += -fno-strict-aliasing
 lib_LTLIBRARIES = liblttng-ust-fd.la
 liblttng_ust_fd_la_SOURCES = \
lttng-ust-fd.c
-liblttng_ust_fd_la_LIBADD = \
-   $(top_builddir)/liblttng-ust/liblttng-ust.la
 
-if LTTNG_UST_BUILD_WITH_LIBDL
-liblttng_ust_fd_la_LIBADD += -ldl
-endif
-if LTTNG_UST_BUILD_WITH_LIBC_DL
-liblttng_ust_fd_la_LIBADD += -lc
-endif
+liblttng_ust_fd_la_LIBADD = \
+   $(top_builddir)/liblttng-ust/liblttng-ust.la \
+   $(DL_LIBS)
 
 liblttng_ust_fd_la_CFLAGS = -DUST_COMPONENT=liblttng-ust-fd $(AM_CFLAGS)
diff --git a/liblttng-ust-fork/Makefile.am b/liblttng-ust-fork/Makefile.am
index 2f0976d4..d05f5b93 100644
--- a/liblttng-ust-fork/Ma

[lttng-dev] [PATCH lttng-ust 2/4] Use config.h to define SONAME major number

[Michael Jeanson]

Signed-off-by: Michael Jeanson 
---
 configure.ac  | 2 +-
 liblttng-ust/Makefile.am  | 2 --
 liblttng-ust/lttng-ust-comm.c | 2 +-
 3 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/configure.ac b/configure.ac
index 431ed21a..9ab76501 100644
--- a/configure.ac
+++ b/configure.ac
@@ -25,7 +25,7 @@ m4_define([UST_LIB_V_MINOR], [0])
 m4_define([UST_LIB_V_PATCH], [0])
 
 AC_SUBST([LTTNG_UST_LIBRARY_VERSION], 
[UST_LIB_V_MAJOR:UST_LIB_V_MINOR:UST_LIB_V_PATCH])
-AC_SUBST([LTTNG_UST_LIBRARY_VERSION_MAJOR], [UST_LIB_V_MAJOR])
+AC_DEFINE([CONFIG_LTTNG_UST_LIBRARY_VERSION_MAJOR], [UST_LIB_V_MAJOR], [Major 
SONAME number of the ust library])
 # note: remember to update tracepoint.h dlopen() to match this version
 # number. TODO: eventually automate by exporting the major number.
 
diff --git a/liblttng-ust/Makefile.am b/liblttng-ust/Makefile.am
index ea4c8f61..15655280 100644
--- a/liblttng-ust/Makefile.am
+++ b/liblttng-ust/Makefile.am
@@ -63,8 +63,6 @@ liblttng_ust_runtime_la_SOURCES = \
string-utils.c \
string-utils.h
 
-liblttng_ust_runtime_la_CFLAGS = 
-DLTTNG_UST_LIBRARY_VERSION_MAJOR=\"$(LTTNG_UST_LIBRARY_VERSION_MAJOR)\"
-
 if HAVE_PERF_EVENT
 liblttng_ust_runtime_la_SOURCES += \
lttng-context-perf-counters.c \
diff --git a/liblttng-ust/lttng-ust-comm.c b/liblttng-ust/lttng-ust-comm.c
index a09f676a..eab2d8eb 100644
--- a/liblttng-ust/lttng-ust-comm.c
+++ b/liblttng-ust/lttng-ust-comm.c
@@ -61,7 +61,7 @@
 #include "getenv.h"
 
 /* Concatenate lttng ust shared library name with its major version number. */
-#define LTTNG_UST_LIB_SO_NAME "liblttng-ust.so." 
LTTNG_UST_LIBRARY_VERSION_MAJOR
+#define LTTNG_UST_LIB_SO_NAME "liblttng-ust.so." 
__ust_stringify(CONFIG_LTTNG_UST_LIBRARY_VERSION_MAJOR)
 
 /*
  * Has lttng ust comm constructor been called ?
-- 
2.17.1

___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

[lttng-dev] [PATCH lttng-ust 3/4] Add silent rules support for docs

[Michael Jeanson]

Signed-off-by: Michael Jeanson 
---
 doc/man/Makefile.am | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/doc/man/Makefile.am b/doc/man/Makefile.am
index fcc4c5c7..f562bfd1 100644
--- a/doc/man/Makefile.am
+++ b/doc/man/Makefile.am
@@ -47,26 +47,35 @@ MAN = $(MAN1) $(MAN3)
 if MAN_PAGES_OPT
 # At this point, we know the user asked to build the man pages.
 if HAVE_ASCIIDOC_XMLTO
+
+asciidoc_verbose = $(asciidoc_verbose_@AM_V@)
+asciidoc_verbose_ = $(asciidoc_verbose_@AM_DEFAULT_V@)
+asciidoc_verbose_0 = @echo "  ASCIIDOC  " $@;
+
+xmlto_verbose = $(xmlto_verbose_@AM_V@)
+xmlto_verbose_ = $(xmlto_verbose_@AM_DEFAULT_V@)
+xmlto_verbose_0 = @echo "  XMLTO " $@;
+
 # Tools to execute:
-ADOC = $(ASCIIDOC) -f $(ASCIIDOC_CONF) -d manpage \
+ADOC = $(asciidoc_verbose)$(ASCIIDOC) -f $(ASCIIDOC_CONF) -d manpage \
-a lttng_version="$(PACKAGE_VERSION)" \
-a 
lttng_ust_register_timeout="@LTTNG_UST_DEFAULT_CONSTRUCTOR_TIMEOUT_MS@"
 
 ADOC_DOCBOOK = $(ADOC) -b docbook
-XTO = $(XMLTO) -m $(XSL_FILE) man
+XTO = $(xmlto_verbose)$(XMLTO) -m $(XSL_FILE) man
 
 # Recipes:
 %.1.xml: $(srcdir)/%.1.txt $(COMMON_DEPS)
$(ADOC_DOCBOOK) -o $@ $<
 
 %.1: %.1.xml $(XSL_FILE)
-   $(XTO) $<
+   $(XTO) $< 2>/dev/null
 
 %.3.xml: $(srcdir)/%.3.txt $(COMMON_DEPS)
$(ADOC_DOCBOOK) -o $@ $<
 
 %.3: %.3.xml $(XSL_FILE)
-   $(XTO) $<
+   $(XTO) $< 2>/dev/null
 
 # Only clean the generated files if we have the tools to generate them again.
 CLEANFILES = $(MAN_XML) $(MAN)
-- 
2.17.1

___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

[lttng-dev] [PATCH lttng-ust 4/4] Add silent mode to examples Makefiles

[Michael Jeanson]

Signed-off-by: Michael Jeanson 
---
 doc/examples/Makefile.am   | 10 +++---
 doc/examples/clock-override/Makefile   |  7 +--
 doc/examples/demo-tracef/Makefile  |  7 +--
 doc/examples/demo-tracelog/Makefile|  7 +--
 doc/examples/demo/Makefile | 22 +++---
 doc/examples/easy-ust/Makefile | 10 +++---
 doc/examples/gen-tp/Makefile   | 24 +++-
 doc/examples/getcpu-override/Makefile  |  7 +--
 doc/examples/hello-static-lib/Makefile | 13 +
 9 files changed, 69 insertions(+), 38 deletions(-)

diff --git a/doc/examples/Makefile.am b/doc/examples/Makefile.am
index 493e07dd..d5d00b09 100644
--- a/doc/examples/Makefile.am
+++ b/doc/examples/Makefile.am
@@ -106,28 +106,24 @@ SUBDIRS_PROXY += gen-tp
 endif
 
 all-local:
-   @if [ x"$(srcdir)" != x"$(builddir)" ]; then \
+   $(AM_V_at)if [ x"$(srcdir)" != x"$(builddir)" ]; then \
for subdir in $(SUBDIRS_PROXY) $(SUBDIRS_JUL) $(SUBDIRS_LOG4J) 
$(SUBDIRS_CMAKE); do \
cp -pfR $(srcdir)/$$subdir $(builddir); \
chmod -R u+w $(builddir)/$$subdir; \
done; \
fi; \
if [ x"$(shell echo "$(top_srcdir)" | grep "^/" | wc -l)" = x"1" ]; 
then \
-   echo "Examples: absolute top_srcdir path $(top_srcdir)"; \
rel_src_subdir=""; \
else \
-   echo "Examples: relative top_srcdir path $(top_srcdir)"; \
rel_src_subdir="../"; \
fi; \
if [ x"$(shell echo "$(top_builddir)" | grep "^/" | wc -l)" = x"1" ]; 
then \
-   echo "Examples: absolute top_builddir path $(top_builddir)"; \
rel_build_subdir=""; \
else \
-   echo "Examples: relative top_builddir path $(top_builddir)"; \
rel_build_subdir="../"; \
fi; \
for subdir in $(SUBDIRS_PROXY); do \
-   (cd $$subdir && $(MAKE) CC="$(CC)" CPPFLAGS="$(CPPFLAGS)" 
AM_CPPFLAGS="$(AM_CPPFLAGS) -I$$rel_src_subdir$(top_srcdir)/include/ 
-I$$rel_build_subdir$(top_builddir)/include/" CFLAGS='$(CFLAGS)' 
AM_CFLAGS='$(AM_CFLAGS)' LDFLAGS="$(LDFLAGS)" AM_LDFLAGS='$(AM_LDFLAGS) 
-L../../../liblttng-ust/.libs -Wl,-rpath="$(PWD)/../../liblttng-ust/.libs/" 
-Wl,-rpath-link="$(PWD)/../../liblttng-ust/.libs/"' 
LTTNG_GEN_TP_PATH="../../../tools/" $(AM_MAKEFLAGS) all && cd ..) || exit 1; \
+   (cd $$subdir && $(MAKE) CC="$(CC)" CPPFLAGS="$(CPPFLAGS)" 
AM_CPPFLAGS="$(AM_CPPFLAGS) -I$$rel_src_subdir$(top_srcdir)/include/ 
-I$$rel_build_subdir$(top_builddir)/include/" CFLAGS='$(CFLAGS)' 
AM_CFLAGS='$(AM_CFLAGS)' LDFLAGS="$(LDFLAGS)" AM_LDFLAGS='$(AM_LDFLAGS) 
-L../../../liblttng-ust/.libs -Wl,-rpath="$(PWD)/../../liblttng-ust/.libs/" 
-Wl,-rpath-link="$(PWD)/../../liblttng-ust/.libs/"' 
LTTNG_GEN_TP_PATH="../../../tools/" AM_V_P="$(AM_V_P)" AM_V_at="$(AM_V_at)" 
$(AM_MAKEFLAGS) all && cd ..) || exit 1; \
done; \
if [ x"$(SUBDIRS_JUL)" != x"" ]; then \
for subdir in $(SUBDIRS_JUL); do \
@@ -162,7 +158,7 @@ all-local:
 
 
 clean-local:
-   @for subdir in $(SUBDIRS_PROXY); do \
+   $(AM_V_at)for subdir in $(SUBDIRS_PROXY); do \
if [ -d $$subdir ]; then \
(cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) clean && cd ..) 
|| exit 1; \
fi; \
diff --git a/doc/examples/clock-override/Makefile 
b/doc/examples/clock-override/Makefile
index 22e5dffb..bd29f179 100644
--- a/doc/examples/clock-override/Makefile
+++ b/doc/examples/clock-override/Makefile
@@ -18,15 +18,18 @@
 LIBS = -ldl# On Linux
 #LIBS = -lc# On BSD
 LOCAL_CPPFLAGS += -I.
+AM_V_P := :
 
 all: lttng-ust-clock-override-example.so
 
 lttng-ust-clock-override-example.o: lttng-ust-clock-override-example.c
-   $(CC) $(CPPFLAGS) $(LOCAL_CPPFLAGS) $(AM_CFLAGS) $(AM_CPPFLAGS) \
+   @if $(AM_V_P); then set -x; else echo "  CC   $@"; fi; \
+   $(CC) $(CPPFLAGS) $(LOCAL_CPPFLAGS) $(AM_CFLAGS) $(AM_CPPFLAGS) 
\
$(CFLAGS) -fpic -c -o $@ $<
 
 lttng-ust-clock-override-example.so: lttng-ust-clock-override-example.o
-   $(CC) -Wl,--no-as-needed -o $@ $(LDFLAGS) $(AM_CFLAGS) \
+   @if $(AM_V_P); then set -x; else echo "  CCLD $@"; fi; \
+   $(CC) -Wl,--no-as-needed -o $@ $(LDFLAGS) $(AM_CFLAGS) \
$(AM_LDFLAGS) $(CFLAGS) -shared -fpic 
lttng-ust-clock-override-example.o
 
 .PHONY: clean
diff --git a/doc/examples/demo-tracef/Makefile 
b/doc/examples/demo-tracef/Makefile
index 1e4544c4..ee207843 100644
--- a/doc/examples/demo-tracef/Makefile
+++ b/doc/examples/demo-tracef/Makefile
@@ -18,15 +18,18 @@
 LIBS = -ldl -llttng-ust# On Linux
 #LIBS = -lc# On BSD
 LOCAL_CPPFLAGS += -I.
+AM_V_P := :
 
 all: demo-tracef
 
 demo-tracef.o: demo-tracef.c
-   $(CC) $(CPPFLAGS) $(LOCAL_CPPFLAGS) $(AM_CFLAGS) $(AM_CPPFLAGS) \
+   @if $(AM_V_P); then set -x; else echo "

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

[Yonghong Yan]

Apologize for the wrong terms. I will ask in another way: I have
multithread code, and if a thread calls lttng_enable_event (...), will it
impact only the calling thread, or the threads spawned after that call, or
all the threads of the process?

Got your answer about vtid context. It is similar to what I am doing. We
want to analyze behavior of all user threads. In the current LTTng, we need
have that vtid field for each event even if it is rare situation that a
thread migrate, and also for analyzing the traces, we need to check each
records and sort the traces according to the vtid. It impacts the
performance of both tracing and analysis. If I want to change the way of
how traces are fed to the buffer in LTTng, how complicated will it be? I am
guessing I will need to at least replace sched_getcpu with vtid (or alike
so all the user threads are numbered from 0), and/or have the ring buffer
bind to the user thread, and more.

Yonghong


On Thu, Dec 20, 2018 at 2:49 PM Mathieu Desnoyers <
mathieu.desnoy...@efficios.com> wrote:

> Hi,
>
> Can you define what you mean by "per-user-thread tracepoint" and
> "whole-user-process" ? AFAIK
> those concepts don't appear anywhere in the LTTng documentations.
>
> Thanks,
>
> Mathieu
>
> - On Dec 19, 2018, at 6:06 PM, Yonghong Yan  wrote:
>
> Got another question about lttng_enable_event(): Using this API will
> impact per-user-thread tracepoint or the whole-user-process? I am thinking
> of the whole process, but want to confirm.
>
> Yonghong
>
>
> On Wed, Dec 19, 2018 at 4:20 PM Mathieu Desnoyers <
> mathieu.desnoy...@efficios.com> wrote:
>
>> Hi Yonghong,
>>
>> - On Dec 19, 2018, at 1:19 PM, Yonghong Yan 
>> wrote:
>>
>> We are experimenting LTTng for tracing multi-threaded program, it works
>> very well for us. Thank you for having this great tool. But we have some
>> concerns about the overhead and scalability of the tracing. Could you share
>> some insight of the following questions?
>> 1. The session domain communicates with the user application via Unix
>> domain socket, from LTTng document. is the communication frequent, such as
>> each event requires communication, or the communication just happens at the
>> beginning to configure user space tracing?
>>
>> This Unix socket is only for "control" of tracing (infrequent
>> communication). The high-throughput tracing data goes through a shared
>> memory map (per-cpu buffers).
>>
>> 2. For the consumer domain, is the consumer domain has a thread per
>> CPU/channel to write to disk or relay the traces, or it is a single
>> threaded-process handling all the channels and ring buffers, which could
>> become a bottleneck if we have large number of user threads all feeding
>> traces?
>>
>> Each consumer daemon is a single thread at the moment. It could be
>> improved by implementing a multithreaded design in the future. It should
>> help especially in NUMA setups, where having the consumer daemon on the
>> same NUMA node as the ring buffer it reads from would minimize the amount
>> of remote NUMA accesses.
>>
>> Another point is cases where I/O is performed to various target locations
>> (different network interfaces or disks). When all I/O goes through the same
>> interface, the bottleneck becomes the block device or the network
>> interface. However, for scenarios involving many network interfaces or
>> block devices, then multithreading the consumer daemon could become useful.
>>
>> This has not been a priority for anyone so far though.
>>
>> 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.
>>
>> 4. So far, the events for tracing can be enabled and disabled from
>> command line, are you considering to have runtime options (APIs) to enable
>> or disable certain events? Or this is the feature that already in or can be
>> implemented in different way?
>>
>> We already expose a public LGPLv2.1 API for this. See lttng-tools:
>>
>> include/lttng/event.h: lttng_enable_event()
>>
>> It is implemented by liblttng-ctl.so
>>
>> 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.

[lttng-dev] [PATCH lttng-tools] Remove duplicate check for dlopen

[Michael Jeanson]

Signed-off-by: Michael Jeanson 
---
 configure.ac | 17 +++--
 1 file changed, 3 insertions(+), 14 deletions(-)

diff --git a/configure.ac b/configure.ac
index bf1ef6f2..fa0edc44 100644
--- a/configure.ac
+++ b/configure.ac
@@ -217,15 +217,18 @@ AC_CHECK_LIB([rt], [clock_gettime, timer_create, 
timer_settime, timer_delete])
 AC_CHECK_LIB([dl], [dlopen], [
have_libdl=yes
libdl_name=dl
+   DL_LIBS="-ldl"
 ], [
# libdl not found, check for dlopen in libc.
AC_CHECK_LIB([c], [dlopen], [
have_libc_dl=yes
libdl_name=c
+   DL_LIBS="-lc"
], [
AC_MSG_ERROR([Cannot find dlopen in libdl nor libc. Use 
[LDFLAGS]=-Ldir to specify their location.])
])
 ])
+AC_SUBST(DL_LIBS)
 
 # Check if libdl has dlmopen support.
 AH_TEMPLATE([HAVE_DLMOPEN], ["Define to 1 if dlmopen is available."])
@@ -570,20 +573,6 @@ AS_IF([test "x$with_lttng_ust" = "xyes"],
 AM_CONDITIONAL([HAVE_LIBLTTNG_UST_CTL], [test "x$with_lttng_ust" = "xyes"])
 
 
-
-# check for dlopen
-AC_CHECK_LIB([dl], [dlopen],
-  [DL_LIBS="-ldl"],
-  [
-#libdl not found, check for dlopen in libc.
-AC_CHECK_LIB([c], [dlopen],
-  [DL_LIBS="-lc"],
-  [AC_MSG_FAILURE([Cannot find dlopen in libdl nor libc. Use 
[LDFLAGS]=-Ldir to specify their location.])]
-)
-  ]
-)
-AC_SUBST(DL_LIBS)
-
 # Check for fmemopen
 AC_CHECK_LIB([c], [fmemopen],
 [
-- 
2.17.1

___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

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

[Mathieu Desnoyers]

It will impact tracing of _all_ threads of _all_ processes tracked by the 
targeted tracing session. 
"lttng_enable_event()" is by no mean a "fast" operation. It is a tracing 
control operation meant to 
be performed outside of fast-paths. 

Changing the design of LTTng from per-cpu to something else would be a 
significant endeavor. 

Thanks, 

Mathieu 

- On Dec 20, 2018, at 3:27 PM, Yonghong Yan  wrote: 

> Apologize for the wrong terms. I will ask in another way: I have multithread
> code, and if a thread calls lttng_enable_event (...), will it impact only the
> calling thread, or the threads spawned after that call, or all the threads of
> the process?

> Got your answer about vtid context. It is similar to what I am doing. We want 
> to
> analyze behavior of all user threads. In the current LTTng, we need have that
> vtid field for each event even if it is rare situation that a thread migrate,
> and also for analyzing the traces, we need to check each records and sort the
> traces according to the vtid. It impacts the performance of both tracing and
> analysis. If I want to change the way of how traces are fed to the buffer in
> LTTng, how complicated will it be? I am guessing I will need to at least
> replace sched_getcpu with vtid (or alike so all the user threads are numbered
> from 0), and/or have the ring buffer bind to the user thread, and more.

> Yonghong

> On Thu, Dec 20, 2018 at 2:49 PM Mathieu Desnoyers < [
> mailto:mathieu.desnoy...@efficios.com | mathieu.desnoy...@efficios.com ] >
> wrote:

>> Hi,

>> Can you define what you mean by "per-user-thread tracepoint" and
>> "whole-user-process" ? AFAIK
>> those concepts don't appear anywhere in the LTTng documentations.

>> Thanks,

>> Mathieu

>> - On Dec 19, 2018, at 6:06 PM, Yonghong Yan < [ mailto:yany...@gmail.com 
>> |
>> yany...@gmail.com ] > wrote:

>>> Got another question about lttng_enable_event(): Using this API will impact
>>> per-user-thread tracepoint or the whole-user-process? I am thinking of the
>>> whole process, but want to confirm.

>>> Yonghong

>>> On Wed, Dec 19, 2018 at 4:20 PM Mathieu Desnoyers < [
>>> mailto:mathieu.desnoy...@efficios.com | mathieu.desnoy...@efficios.com ] >
>>> wrote:

 Hi Yonghong,

 - On Dec 19, 2018, at 1:19 PM, Yonghong Yan < [ 
 mailto:yany...@gmail.com |
 yany...@gmail.com ] > wrote:

> We are experimenting LTTng for tracing multi-threaded program, it works 
> very
> well for us. Thank you for having this great tool. But we have some 
> concerns
> about the overhead and scalability of the tracing. Could you share some 
> insight
> of the following questions?
> 1. The session domain communicates with the user application via Unix 
> domain
> socket, from LTTng document. is the communication frequent, such as each 
> event
> requires communication, or the communication just happens at the 
> beginning to
> configure user space tracing?

 This Unix socket is only for "control" of tracing (infrequent 
 communication).
 The high-throughput tracing data goes through a shared memory map (per-cpu
 buffers).

> 2. For the consumer domain, is the consumer domain has a thread per 
> CPU/channel
> to write to disk or relay the traces, or it is a single threaded-process
> handling all the channels and ring buffers, which could become a 
> bottleneck if
> we have large number of user threads all feeding traces?

 Each consumer daemon is a single thread at the moment. It could be 
 improved by
 implementing a multithreaded design in the future. It should help 
 especially in
 NUMA setups, where having the consumer daemon on the same NUMA node as the 
 ring
 buffer it reads from would minimize the amount of remote NUMA accesses.

 Another point is cases where I/O is performed to various target locations
 (different network interfaces or disks). When all I/O goes through the same
 interface, the bottleneck becomes the block device or the network 
 interface.
 However, for scenarios involving many network interfaces or block devices, 
 then
 multithreading the consumer daemon could become useful.

 This has not been a priority for anyone so far though.

> 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-s