Hello Mathieu, Am Do., 20. Mai 2021 um 16:16 Uhr schrieb Mathieu Desnoyers <mathieu.desnoy...@efficios.com>: > > ----- On May 20, 2021, at 9:42 AM, Norbert Lange nolang...@gmail.com wrote: > > > Am Do., 20. Mai 2021 um 15:28 Uhr schrieb Mathieu Desnoyers > > <mathieu.desnoy...@efficios.com>: > >> > >> ----- On May 20, 2021, at 8:46 AM, Norbert Lange nolang...@gmail.com wrote: > >> > >> > Am Mi., 19. Mai 2021 um 20:52 Uhr schrieb Mathieu Desnoyers > >> > <mathieu.desnoy...@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