public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
To: Mathieu Desnoyers <compudj@krystal.dyndns.org>
Cc: ltt-dev@shafik.org, systemtap@sources.redhat.com
Subject: Re: Interoperability of LTTng and LTTV with SystemTAP
Date: Sat, 17 Dec 2005 23:22:00 -0000	[thread overview]
Message-ID: <20051217223300.GB8314@dmt.cnet> (raw)
In-Reply-To: <20051214022515.GA1488@Krystal>

Hi Mathieu,

On Tue, Dec 13, 2005 at 09:25:15PM -0500, Mathieu Desnoyers wrote:

<snip>

> Frank asked me, at the end of our IRC discussion, if I could send some numbers
> about how much information is transferred. Here is the first result : a trace
> taken on a system used for start/stop of web broser (mozilla) and doing a "find"
> on the root of the system. I plan to do the same on heavily loaded
> system (I am trying to get an heavy commercial application for this) and very
> heavily loaded system (I will try ping -f and a few others) as soon as I have
> the time.
> 
> I have also been asked about the impact of the copy of the information to disk
> on the system behavior. The percentage of cpu time used is not relevant in this
> first usage scenario because the system was most of the time idle. Still, about
> 1.79% (cpu 0) and 1.89% (cpu 1) of cpu time has been used by the disk writer
> daemon, which is not much considering that the system usage was 6.78% for cpu 0
> and 9.79% for cpu 1. A heavily loaded system will give us a better insight.

It might be interesting to measure the impact of tracing on the
performance of synthetic workloads (preferably ones which are
meaningful/mimic behaviour of real loads). 

Ie. the overhead of tracing under different loads.

No?

> However, I would say that probe effect at the call site is much more important
> than the effect of a much lower priority disk writer daemon. 

It depends really. The log disk writes could interfere badly with
sequential disk read/write streams, and workloads dominated by such 
kind of accesses would suffer more from that than from the CPU 
effect.

> For the probe effect, the microbenchmarks I made tells that logging an event takes about 
> 220 ns.

And blows a few cachelines? 

> Here are the results. Note that I have taken a short trace (15 seconds) just
> because I was in a hurry before preparing a presentation at that moment.

Have you tried to use any sort of PMC hardware to measure the effects
more precisely (including cache effects)?

Best wishes

  parent reply	other threads:[~2005-12-17 23:05 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-14  4:05 Mathieu Desnoyers
2005-12-14 18:25 ` Tom Zanussi
2005-12-14 18:47   ` Tom Zanussi
2005-12-16  0:55 ` Jose R. Santos
2005-12-16  1:09 ` Interoperability of LTTng and LTTV with SystemTAP (heavy usage) Mathieu Desnoyers
2005-12-17 14:27   ` LTTng very heavy system usage scenario Mathieu Desnoyers
2005-12-17 20:00     ` LTTng very heavy system usage scenario : probes Mathieu Desnoyers
2005-12-17 23:05   ` [ltt-dev] Re: Interoperability of LTTng and LTTV with SystemTAP (heavy usage) Mathieu Desnoyers
2005-12-19 22:12   ` Martin Hunt
2005-12-17 23:22 ` Marcelo Tosatti [this message]
2005-12-18 12:59   ` Interoperability of LTTng and LTTV with SystemTAP 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=20051217223300.GB8314@dmt.cnet \
    --to=marcelo.tosatti@cyclades.com \
    --cc=compudj@krystal.dyndns.org \
    --cc=ltt-dev@shafik.org \
    --cc=systemtap@sources.redhat.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 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 read-only IMAP folder(s) and NNTP newsgroup(s).