On 9/10/23 10:18, Mousa, Anas wrote:
Hey Mathieu,
Hi Anas,
We see that upon recording a tracepoint, there are multiple stages of
reserve-commit-write, where atomics and shared memory accesses take up a big part of the
recording time,
we're wondering, is there a "light-mode" of recording a tracepoint
involving less logic or
a mode which can potentially have lower latency?
I've been working on the rseq(2) system call for a few years now, and
this is intended to help reduce the cost of lttng-ust's ring buffer
atomics on the tracing fast-path. The road ahead there is integration of
rseq with lttng-ust, which did not show up on our customer feature
requirements radar yet.
In terms of logic involved in the lttng-ust tracepoints, I hope that my
current work on "libside" will help steer away from tracepoint providers
based on macros and generated code, replacing this by an efficient
bytecode interpreter. This should allow me to inline many of the calls
that are currently needed between the tracepoint probe provider and the
lttng-ust ring buffer. Again, this is an area where I think we can have
great speed improvements, but it did not show up on our customer's
feature requirement radar yet.
Also, are there any recent docs to share regarding tracepoint latency?
There is a Polytechnique student who extensively analyzed this recently.
Michel, do you have a pointer to his work ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
