From: Colin Ian King <colin.king@canonical.com>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: lttng-dev@lists.lttng.org, kernel-team@lists.ubuntu.com
Subject: Re: Feedback on your ARM LTTng benchmarks
Date: Thu, 12 Sep 2013 23:27:44 +0100 [thread overview]
Message-ID: <52323FE0.2050904@canonical.com> (raw)
In-Reply-To: <20130912214457.GA7783@Krystal>
Hi Mathieu,
On 12/09/13 22:44, Mathieu Desnoyers wrote:
> Hi Colin,
>
> I just read your post on:
>
> https://lists.ubuntu.com/archives/kernel-team/2013-May/028450.html
>
> and, although I'm very pleased to see that LTTng provides good
> performances in your tests, there is a small detail on your benchmarking
> approach I would like to bring to your attention. If you followed the
> benchmarking procedure used by Romik Guha Anjoy and Soumya Kanti
> Chakraborty's "Efficiency of Lttng as a Kernel and Userspace Tracer"
> work, you only have part of the picture. I pointed this issue to them
> when I stumbled on their work after it has been published.
>
> You see, they only benchmark the equivalent of lttng-consumerd and
> lttng-sessiond (in the lttng 0.x days, that was lttd). They entirely
> miss the impact of the lttng-modules kernel tracer and lttng-ust
> userspace tracer: the parts that write into the ring buffers.
>
> This part is slightly harder to benchmark. This is why I relied on
> system benchmarks with typical workloads to measure the overall system
> slowdown in my thesis
> (http://www.lttng.org/pub/thesis/desnoyers-dissertation-2009-12.pdf)
> rather than use profiling.
>
> If you only profile lttng-sessiond and lttng-consumerd, you will end up
> noticing a very tiny impact indeed: while tracing is active,
> lttng-sessiond is almost never active. lttng-consumerd needs to
> transport the data, which indeed brings some overhead. However, if you
> use lttng's flight recorder tracing (with snapshots) introduced in lttng
> 2.3, the consumerd is entirely out of the picture: it's just writing
> into memory buffers. Even then, the lttng-modules and lttng-ust parts
> of the tracer have _some_ impact when writing into the buffers from the
> kernel and user-space application contexts.
>
> So overall, there is a part of the lttng footprint not accounted for.
> It's very small, but it exists.
That is very useful to know, many thanks for the clarification. Do you
have any ARM based benchmarks that can give us an idea of the overhead
that I failed to account for?
>
> I just want to make sure that nobody can say later than "lttng is fast"
> claim is based on bogus benchmarks. It is very fast, yes, but I
> recommend revisiting your benchmarking approach if you based it solely
> on Romik Guha Anjoy and Soumya Kanti Chakraborty's work.
>
> On typical benchmarks, my own results were usually under 5% of overhead
> system-side (see my thesis for details).
Is that specific to any particular architecture? I was concerned about
the impact on processors with relatively small instruction and data
caches such as ARM processors.
>
> Thank you !
>
> Mathieu
>
Thanks again for taking the effort to enlighten me.
Regards,
Colin
next parent reply other threads:[~2013-09-12 22:27 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20130912214457.GA7783@Krystal>
2013-09-12 22:27 ` Colin Ian King [this message]
2013-09-13 0:45 ` Feedback on your ARM LTTng benchmarks Mathieu Desnoyers
2013-09-12 21:44 Mathieu Desnoyers
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=52323FE0.2050904@canonical.com \
--to=colin.king@canonical.com \
--cc=kernel-team@lists.ubuntu.com \
--cc=lttng-dev@lists.lttng.org \
--cc=mathieu.desnoyers@efficios.com \
/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.