[RFC]-Approaches to user space probes

[Stone, Joshua I]

Keshavamurthy Anil S wrote:
> On Fri, Jan 27, 2006 at 10:45:02AM -0800, Stone, Joshua I wrote:
>> 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:
> Sure, their is some advantange in 4, but the thing we need to see
> is whether this apporach suits probing different kinds of
> application(mainly java apps).

It may be possible to just have a user-mode daemon manage the
communication with the JVM (through JVMTI or the like).  So I don't
method 4 excludes other application types, though it may make some
things harder than they would be in methods 1-3.


> [...]
> If in the user program, strlen() is called only once and
> assuming that the return probe failed to initialize due to
> no kretprobe instance, your return probe handler will
> never gets fired and your hence in_strlen[tid()] will
> never gets reset and  the pagefault count will have
> wrong value.

Well, in a world where kretprobes can miss, the best you can do is a
"statistical" sampling.  If an event only heppens once, it may not be of
much interest anyway.  (It would be nice to see this limitation of
kretprobes go away, but I haven't reviewed the code enough to know why
that limitation is necessary...)

There is a real issue of stale 'flags' using up all of the map space,
but this can be alleviated if we enable wrapping on maps.

Do we have any hooks back to the stap module if a kretprobe instance
fails?  It would be nice if the runtime could keep track of that and
include it in the MAXSKIPPED count...


Josh