This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: syscall tracing overheads: utrace vs. kprobes
- From: Roland McGrath <roland at redhat dot com>
- To: "Frank Ch. Eigler" <fche at redhat dot com>
- Cc: systemtap at sources dot redhat dot com, utrace-devel at redhat dot com
- Date: Tue, 28 Apr 2009 11:10:10 -0700 (PDT)
- Subject: Re: syscall tracing overheads: utrace vs. kprobes
- References: <20090428170117.GA30001@redhat.com>
Btw, it is probably wise to use the syscall() function just so you are
always sure you are testing system call details rather than libc details.
The standard microbenchmark is syscall(__NR_getpid). That is the minimal
system call, vs. close that takes locks and so forth (so it's getting more
issues into the test than the one you are looking at).
The microbenchmark makes that seem like more of a sensical comparison than
it really is. They are really apples and oranges. The TIF_SYSCALL_TRACE
types (process.syscall) add some overhead to every system call. The probe
types (kprobe/tracepoint/marker) add overhead only to the probed call.
In real situations, there will be many different syscalls made. In tracing
scenarios where you are only probing a few individual ones (especially if
they are not the cheapest or most frequent), the distribution of overheads
will be quite different.
Thanks,
Roland