From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6330 invoked by alias); 17 Dec 2005 23:05:42 -0000 Received: (qmail 6322 invoked by uid 22791); 17 Dec 2005 23:05:42 -0000 X-Spam-Status: No, hits=0.0 required=5.0 tests=BAYES_50 X-Spam-Check-By: sourceware.org Received: from hera.kernel.org (HELO hera.kernel.org) (140.211.167.34) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 17 Dec 2005 23:05:40 +0000 Received: from dmt.cnet (localhost [127.0.0.1]) by hera.kernel.org (8.13.1/8.13.1) with ESMTP id jBHN5Pe8019284; Sat, 17 Dec 2005 15:05:26 -0800 Received: from dmt.cnet (dmt.cnet [127.0.0.1]) by dmt.cnet (Postfix) with ESMTP id 6C91630AAE9; Sat, 17 Dec 2005 20:33:06 -0200 (BRST) Received: (from marcelo@localhost) by dmt.cnet (8.13.4/8.13.4/Submit) id jBHMX0cf010075; Sat, 17 Dec 2005 20:33:00 -0200 Date: Sat, 17 Dec 2005 23:22:00 -0000 From: Marcelo Tosatti To: Mathieu Desnoyers Cc: ltt-dev@shafik.org, systemtap@sources.redhat.com Subject: Re: Interoperability of LTTng and LTTV with SystemTAP Message-ID: <20051217223300.GB8314@dmt.cnet> References: <20051214022515.GA1488@Krystal> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051214022515.GA1488@Krystal> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.85, clamav-milter version 0.85 on localhost X-Virus-Status: Clean X-IsSubscribed: yes Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2005-q4/txt/msg00471.txt.bz2 Hi Mathieu, On Tue, Dec 13, 2005 at 09:25:15PM -0500, Mathieu Desnoyers wrote: > 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