From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Beau Belgrave <beaub@linux.microsoft.com>
Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
Song Liu <song@kernel.org>, rostedt <rostedt@goodmis.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
linux-trace-devel <linux-trace-devel@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
bpf <bpf@vger.kernel.org>, netdev <netdev@vger.kernel.org>,
linux-arch <linux-arch@vger.kernel.org>
Subject: Re: [PATCH] tracing/user_events: Add eBPF interface for user_event created events
Date: Wed, 30 Mar 2022 15:57:26 -0400 (EDT) [thread overview]
Message-ID: <1402984893.199881.1648670246676.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <20220330191551.GA2377@kbox>
----- On Mar 30, 2022, at 3:15 PM, Beau Belgrave beaub@linux.microsoft.com wrote:
> On Wed, Mar 30, 2022 at 11:22:32AM -0700, Alexei Starovoitov wrote:
>> On Wed, Mar 30, 2022 at 9:34 AM Beau Belgrave <beaub@linux.microsoft.com> wrote:
>> > > >
>> > > > But you are fine with uprobe costs? uprobes appear to be much more costly
>> > > > than a syscall approach on the hardware I've run on.
>>
>> Care to share the numbers?
>> uprobe over USDT is a single trap.
>> Not much slower compared to syscall with kpti.
>>
>
> Sure, these are the numbers we have from a production device.
>
> They are captured via perf via PERF_COUNT_HW_CPU_CYCLES.
> It's running a 20K loop emitting 4 bytes of data out.
> Each 4 byte event time is recorded via perf.
> At the end we have the total time and the max seen.
>
> null numbers represent a 20K loop with just perf start/stop ioctl costs.
>
> null: min=2863, avg=2953, max=30815
> uprobe: min=10994, avg=11376, max=146682
> uevent: min=7043, avg=7320, max=95396
> lttng: min=6270, avg=6508, max=41951
>
> These costs include the data getting into a buffer, so they represent
> what we would see in production vs the trap cost alone. For uprobe this
> means we created a uprobe and attached it via tracefs to get the above
> numbers.
[...]
I assume here that by "lttng" you specifically refer to lttng-ust (LTTng's
user-space tracer), am I correct ?
By removing the "null" baseline overhead, my rough calculations are that the
average overhead for lttng-ust in your results is (in cpu cycles):
6270-2863 = 3555
So I'm unsure what is the frequency of your CPU, but guessing around 3.5GHz
this is in the area of 1 microsecond. On an Intel CPU, this is much larger
than what I would expect.
Can you share your test program, hardware characteristics, kernel version,
glibc version, and whether the program is compiled as a 32-bit or 64-bit
binary ?
Can you confirm that lttng-ust is not calling one getcpu system call per
event ? This might be the case if run a 32-bit x86 binary and have a
glibc < 2.35, or a kernel too old to provide CONFIG_RSEQ or don't have
CONFIG_RSEQ=y in your kernel configuration. You can validate this by
running your lttng-ust test program with a system call tracer.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
next prev parent reply other threads:[~2022-03-30 19:57 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-29 18:19 [PATCH] tracing/user_events: Add eBPF interface for user_event created events Beau Belgrave
2022-03-29 19:50 ` Alexei Starovoitov
2022-03-29 20:10 ` Beau Belgrave
2022-03-29 22:31 ` Alexei Starovoitov
2022-03-29 23:11 ` Beau Belgrave
2022-03-29 23:54 ` Alexei Starovoitov
2022-03-30 16:06 ` Song Liu
2022-03-30 16:34 ` Beau Belgrave
2022-03-30 18:22 ` Alexei Starovoitov
2022-03-30 19:15 ` Beau Belgrave
2022-03-30 19:57 ` Mathieu Desnoyers [this message]
2022-03-30 21:24 ` Beau Belgrave
2022-03-30 20:39 ` Alexei Starovoitov
2022-03-30 21:27 ` Beau Belgrave
2022-03-30 21:57 ` Alexei Starovoitov
2022-03-30 5:22 ` Masami Hiramatsu
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=1402984893.199881.1648670246676.JavaMail.zimbra@efficios.com \
--to=mathieu.desnoyers@efficios.com \
--cc=alexei.starovoitov@gmail.com \
--cc=beaub@linux.microsoft.com \
--cc=bpf@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-devel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=song@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).