From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10241 invoked by alias); 20 Apr 2010 07:59:16 -0000 Received: (qmail 10221 invoked by uid 22791); 20 Apr 2010 07:59:15 -0000 X-SWARE-Spam-Status: No, hits=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 20 Apr 2010 07:59:11 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o3K7x7QC031452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Apr 2010 03:59:07 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o3K7x5ji018807; Tue, 20 Apr 2010 03:59:06 -0400 Subject: RE: Static/dynamic userspace/kernel trace From: Mark Wielaard To: Dominique Toupin Cc: "Frank Ch. Eigler" , "gdb@sourceware.org" , "systemtap@sourceware.org" In-Reply-To: References: <20100419141356.GC4823@redhat.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 20 Apr 2010 07:59:00 -0000 Message-ID: <1271750345.2571.23.camel@hermans.wildebeest.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2010-04/txt/msg00062.txt.bz2 On Mon, 2010-04-19 at 15:50 -0400, Dominique Toupin wrote: > I agree that GDB could use a better ptrace. > > Regarding tracing, for me the main use case is to get the data out of > the system very fast and with very low overhead, besides conditional > tracing and a few minor things, most of the analysis is done on the > host side, either after the fact or in streaming mode. Doing > historical analysis on the target or big actions are not an option for > me. I guess in the IT industry more cycles are available to do those > kinds of analysis directly on the target server. One of the advantages of pre-filtering your tracing results is that the overhead will be a lot lower than having to process a stream of multi-megabytes i/o to disk or off an machines. With SystemTap I am often not doing any kind of real analysis of the trace data on the server itself, because it makes it possible to have the trace results in a compact enough format that the results can be directly interpreted. Having a very low overhead pre-filter of the trace output using full expressions based on context variables, keeping statistics through aggregate state variables and deciding what to push through the trace output buffer using formatted output and data kept in associative arrays helps a lot. Since all can be done without incurring extra i/o, context-switches or external/post filtering it makes interpreting/analyzing the actual trace data a lot easier and lower overhead. It might also help in your use case, since you don't have to push multi-megabytes of trace data off a machine but can tailor the trace buffers to only have a couple of K of targeted output. Cheers, Mark