This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
RE: [RFC]-Approaches to user space probes
- From: "Stone, Joshua I" <joshua dot i dot stone at intel dot com>
- To: <prasanna at in dot ibm dot com>, <systemtap at sources dot redhat dot com>
- Cc: <suparna at in dot ibm dot com>, <ak at suse dot de>, <roland at redhat dot com>, "Keshavamurthy, Anil S" <anil dot s dot keshavamurthy at intel dot com>, <varap at us dot ibm dot com>
- Date: Fri, 27 Jan 2006 10:45:02 -0800
- Subject: RE: [RFC]-Approaches to user space probes
Prasanna S Panchamukhi wrote:
> 1. Attaching or loading the application into the tool.
> 2. Using a jump instruction to a trampoline and trampoline
> executing the instrumented code.
> 3. Using a breakpoint instruction and changing the instruction
> point to the instrumentaiton code which is part of user
> address space.
> 4. Using a breakpoint instruction and executing the
> instrumentation code within the breakpoint handler.
An advantage I see in 4 is the ability to have scripts with a mix of
kernel & user probes. This could let you do some interesting
correlations, perhaps something like:
# Figure out if calls to strlen are causing page faults, and by whom
global in_strlen, strlen_pagefaults
probe user.module("/lib/libc.so.6").function("strlen") {
in_strlen[tid()] = 1
}
probe kernel.function("do_page_fault") {
if (in_strlen[tid()])
strlen_pagefaults[execname()] <<< 1
}
probe user.module("/lib/libc.so.6").function("strlen").return {
delete in_strlen[tid()]
}
probe end {
foreach (name in strlen_pagefaults)
printf("%s: %d\n", name, strlen_pagefaults[name])
}
I don't think this sort of thing would be easy to implement with 1-3.
You might be able to record timestamps and try to correlate the data
later, but that's not as reliable.
Josh