This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: question on system tap
- From: fche at redhat dot com (Frank Ch. Eigler)
- To: "Hebenstreit, Michael" <michael dot hebenstreit at intel dot com>
- Cc: "systemtap at sources dot redhat dot com" <systemtap at sources dot redhat dot com>
- Date: Wed, 27 Jan 2010 13:49:21 -0500
- Subject: Re: question on system tap
- References: <6AF28EB9F93A354894F2F3916DF6F96E0C97A99D36@orsmsx510.amr.corp.intel.com>
"Hebenstreit, Michael" <michael.hebenstreit@intel.com> writes:
> [...]
> a) I start with instrumenting a kernel function A
> b) I run my benchmark
> c) the output should tell me which functions were CALLED by A and the timestamp when they return to A
> d) for those function that interest me more I repeat this procedure
> this way my instrumentation is kept light; I could not find any way to do this with systemtap (maybe a different tool would be better?)
Function-by-function tracing is by nature expensive, even with tools
other than systemtap. Something like para-callgraph.stp should give
some useful data.
http://sourceware.org/systemtap/examples/keyword-index.html#CALLGRAPH
You'd identify function A with the second parameter, and all the
candidate functions in the call graph with the first parameter, as in:
# stap para-callgraph.stp 'kernel.function("*@fs/*")' 'module("lustre").function("A")'
If you want to designate the candidate functions with more than one
probe point, as in kernel.something as well as
module/lustre.something, then you'll need to modify the script and
basically hand-substitute in $1. Same for the enable/disable trigger
$2.
This report gives you a lot of information, including parameter
values. If you want less info (thus let the script run faster and
smaller), you can simplify the printf() in the script to remove
$$parms.
See also the older version of this script with a bit more narrative:
http://sourceware.org/systemtap/wiki/WSCallGraph
- FChE