This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Interoperability of LTTng and LTTV with SystemTAP
- From: Marcelo Tosatti <marcelo dot tosatti at cyclades dot com>
- To: Mathieu Desnoyers <compudj at krystal dot dyndns dot org>
- Cc: ltt-dev at shafik dot org, systemtap at sources dot redhat dot com
- Date: Sat, 17 Dec 2005 20:33:00 -0200
- Subject: Re: Interoperability of LTTng and LTTV with SystemTAP
- References: <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