All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michel Dagenais via lttng-dev <lttng-dev@lists.lttng.org>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: lttng-dev@lists.lttng.org
Subject: Re: [lttng-dev] Profiling LTTng tracepoint latency on different arm platforms
Date: Mon, 11 Sep 2023 12:20:53 -0400 (EDT)	[thread overview]
Message-ID: <454808411.14773142.1694449253211.JavaMail.zimbra@polymtl.ca> (raw)
In-Reply-To: <9fad646e-46bf-9229-81cb-93a237db2922@efficios.com>

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.desnoyers@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

      reply	other threads:[~2023-09-11 16:26 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-20 10:27 [lttng-dev] Profiling LTTng tracepoint latency on different arm platforms Mousa, Anas via lttng-dev
2023-06-20 14:20 ` Mathieu Desnoyers via lttng-dev
2023-06-20 18:03   ` Mathieu Desnoyers via lttng-dev
2023-06-21  5:39     ` Yitschak, Yehuda via lttng-dev
2023-06-21 13:47       ` Mathieu Desnoyers via lttng-dev
2023-06-21 14:21         ` Yitschak, Yehuda via lttng-dev
2023-09-10 14:18           ` Mousa, Anas via lttng-dev
2023-09-11 15:52             ` Mathieu Desnoyers via lttng-dev
2023-09-11 16:20               ` Michel Dagenais via lttng-dev [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=454808411.14773142.1694449253211.JavaMail.zimbra@polymtl.ca \
    --to=lttng-dev@lists.lttng.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=michel.dagenais@polymtl.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.