Re: User-space probes: Plan B+

[fche at redhat dot com (Frank Ch. Eigler)]

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