Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)

[Jim Keniston <jkenisto@us.ibm.com>]

On Tue, 2010-01-19 at 10:07 +0200, Avi Kivity wrote:
> On 01/19/2010 12:15 AM, Jim Keniston wrote:
> >
> >> I don't like the idea but if the performance benefits are real (are
> >> they?),
> >>      
> > Based on what seems to be the closest thing to an apples-to-apples
> > comparison -- counting the number of calls to a specified function --
> > uprobes is 6-7 times faster than the ptrace-based equivalent, ltrace -c.
> > And of course, uprobes provides much, much more flexibility, appears to
> > scale better, and works with multithreaded apps.
> >
> > Likewise, FWIW, utrace is more than 10x faster than strace -c in
> > counting system calls.
> >
> >    
> 
> This is still with a kernel entry, yes?

Yes, this involves setting a breakpoint and trapping into the kernel
when it's hit.  The 6-7x figure is with the current 2-trap approach
(breakpoint, single-step).  Boosting could presumably make that more
like 12-14x.

> Do you have plans for a variant 
> that's completely in userspace?

I don't know of any such plans, but I'd be interested to read more of
your thoughts here.  As I understand it, you've suggested replacing the
probed instruction with a jump into an instrumentation vma (the XOL
area, or something similar).  Masami has demonstrated -- through his
djprobes enhancement to kprobes -- that this can be done for many x86
instructions.

What does the code in the jumped-to vma do?  Is the instrumentation code
that corresponds to the uprobe handlers encoded in an ad hoc .so?

BTW, when some people say "completely in userspace," they mean something
like ptrace, where the kernel is still heavily involved but the
instrumentation code runs in user space.  The ubp layer is intended to
support that model as well.  In our various implementations of the XOL
vma/address area, however, the XOL area is either created on exec or
created/expanded only by the probed process.

Jim