This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: User-space probes: Plan B+
- From: fche at redhat dot com (Frank Ch. Eigler)
- To: Jim Keniston <jkenisto at us dot ibm dot com>
- Cc: systemtap at sources dot redhat dot com
- Date: 25 Aug 2006 11:28:01 -0400
- Subject: Re: User-space probes: Plan B+
- References: <1156468404.2848.5.camel@dyn9047018079.beaverton.ibm.com>
Jim Keniston <jkenisto@us.ibm.com> writes:
> [...] I tried an approach based on ptrace, with no kernel
> enhancements, but it lacked certain necessary features (e.g., #2-5
> below), probe overhead was 12-15x worse than Prasanna's approach
So 12-15 us per probe hit rather than 1 us per kprobe.
> and I couldn't get it to work when probing multiple processes.[...]
Yeah, you'd have to have had several cooperating prober processes.
> [...] b. The "tracer" process detects events (e.g., probe hits) by
> polling rather than catching SIGCHLD signals. [...]
Polling -- but surely not in a busy loop!
> Here are the requirements we will satisfy with this approach.
> 0. Per-process (not per-executable) tracing.
Plus we may need a facility to propagate probes to child processes.
> 1. Instrumentation can be coded entirely as a user-space app...
I am not aware of this being a *requirement*. To my mind, it is an
unfortunate implementation artifact. Running in kernel space but in
the traced processes' user context would be better.
> [...] 3. A user-mode tracer can invoke a previously registered
> kernel-mode handler, so we have simple and efficient communication
> between user- and kernel-mode instrumentation. [...]
How is this registration aspect supposed to work? Is something
keeping us from compiling & registering this instrumentation
dynamically, the same way we do normal kprobes handlers?
- FChE