[lttng-dev] Profiling LTTng tracepoint latency on different arm platforms

[Mathieu Desnoyers]

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