This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Performance Impact of Systemtap
- From: fche at redhat dot com (Frank Ch. Eigler)
- To: ydev <ydev at cs dot utah dot edu>
- Cc: <systemtap at sourceware dot org>
- Date: Wed, 07 Sep 2011 10:26:16 -0400
- Subject: Re: Performance Impact of Systemtap
- References: <cb5b1d6ea5cfb1a47de73cc67487972d@cs.utah.edu>
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