Re: [lttng-dev] Profiling LTTng tracepoint latency on different arm platforms
Mathieu Desnoyers via lttng-dev <[email protected]>
| Newsgroups | org.lttng.lists.lttng-dev |
|---|---|
| Message-ID | <[email protected]> |
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 [email protected] https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev