From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8156 invoked by alias); 7 Sep 2011 14:26:40 -0000 Received: (qmail 8145 invoked by uid 22791); 7 Sep 2011 14:26:39 -0000 X-SWARE-Spam-Status: No, hits=-6.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS 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; Wed, 07 Sep 2011 14:26:19 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p87EQHmp003803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Sep 2011 10:26:17 -0400 Received: from fche.csb (vpn-8-15.rdu.redhat.com [10.11.8.15]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p87EQG4F015587; Wed, 7 Sep 2011 10:26:16 -0400 Received: by fche.csb (Postfix, from userid 2569) id 24D7A5812F; Wed, 7 Sep 2011 10:26:16 -0400 (EDT) To: ydev Cc: Subject: Re: Performance Impact of Systemtap References: From: fche@redhat.com (Frank Ch. Eigler) Date: Wed, 07 Sep 2011 14:26:00 -0000 In-Reply-To: (ydev@cs.utah.edu's message of "Tue, 06 Sep 2011 13:45:15 -0600") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2011-q3/txt/msg00295.txt.bz2 ydev wrote: > I want to measure the overhead introduced by systemtap scripts. For > example, say I were to introduce a SCSI fault during a read or write > op and I want to measure the overhead by systemtap in doing this. [...] General time costs come in two pieces: the costs of dispatching the underlying event to the systemtap module, and the execution time of the systemtap probe handler itself. The former depends on what kind of probe point you attach to (and may vary with kernel version, architecture, tracepoints cheaper than kprobes, etc.); the latter depends on your script contents (and may very with systemtap version). The former may be (under)estimated with microbenchmarks that repeatedly trigger the particular kind of probe for a null kind of handler (as in a -DSTP_ALIBI mode run). The latter may be (under)estimated with stap -t (timing mode), which prints cycles taken up by the handlers themselves. The best way is to measure the impact of your particular workload. It may be immeasurably small there. - FChE