Re: [lttng-dev] reading context fields causes syscalls

[Norbert Lange via lttng-dev <lttng-dev@lists.lttng.org>]

Hello Mathieu,

Am Do., 20. Mai 2021 um 16:16 Uhr schrieb Mathieu Desnoyers
<mathieu.desnoyers@efficios.com>:
>
> ----- On May 20, 2021, at 9:42 AM, Norbert Lange nolange79@gmail.com wrote:
>
> > Am Do., 20. Mai 2021 um 15:28 Uhr schrieb Mathieu Desnoyers
> > <mathieu.desnoyers@efficios.com>:
> >>
> >> ----- On May 20, 2021, at 8:46 AM, Norbert Lange nolange79@gmail.com wrote:
> >>
> >> > Am Mi., 19. Mai 2021 um 20:52 Uhr schrieb Mathieu Desnoyers
> >> > <mathieu.desnoyers@efficios.com>:
> >> >>
> >> >> ----- On May 19, 2021, at 8:11 AM, lttng-dev lttng-dev@lists.lttng.org wrote:
> >> >>
> >> >> > Hello,
> >> >> >
> >> >> > Several context fields will cause a syscall atleast the first time a
> >> >> > tracepoint is
> >> >> > recorded. For example all of the following:
> >> >> >
> >> >> > `lttng add-context -c chan --userspace --type=vpid --type=vtid --type=procname`
> >> >> >
> >> >> > Each of them seems cached in TLS however, and most should never change
> >> >> > after startup.
> >> >> >
> >> >> > As I am using Lttng over Xenomai, syscalls are strictly forbidden, I
> >> >> > would like to have some function that prepares all data, which I can
> >> >> > call on each thread before it switches to realtime work.
> >> >> >
> >> >> > Kinda similar to urcu_bp_register_thread, I'd like to have some
> >> >> > `lttng_ust_warmup_thread` function that fetches the context values
> >> >> > that can be cached. (urcu_bp_register_thread should be called there
> >> >> > aswell)
> >> >> > I considered just doing a tracepoint, but AFAIK the channel can be
> >> >> > changed/configured after the process is running. So this is not robust
> >> >> > enough.
> >> >>
> >> >> The new lttng_ust_init_thread() API in lttng-ust 2.13 would be the right
> >> >> place to do this I think:
> >> >>
> >> >> /*
> >> >>  * Initialize this thread's LTTng-UST data structures. There is
> >> >>  * typically no need to call this, because LTTng-UST initializes its
> >> >>  * per-thread data structures lazily, but it should be called explicitly
> >> >>  * upon creation of each thread before signal handlers nesting over
> >> >>  * those threads use LTTng-UST tracepoints.
> >> >>  */
> >> >>
> >> >> It would make sense that this new initialization helper also initializes
> >> >> all contexts which cache the result of a system call. Considering that
> >> >> contexts can be used from the filter and capture bytecode interpreter, as
> >> >> well as contexts added to channels, I think we'd need to simply initialize
> >> >> them all.

Any update on that, is there an list of open points/features for lttng?

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