You are probably referring to the work of Mohammad Gebai: Survey and Analysis of Kernel and Userspace Tracers on Linux: Design, Implementation, and Overhead
https://dl.acm.org/doi/abs/10.1145/3158644 ----- Le 11 Sep 23, à 11:52, Mathieu Desnoyers mathieu.desnoy...@efficios.com a écrit : > 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
