Messages in this thread | | | Subject | Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP) | From | Jim Keniston <> | Date | Tue, 19 Jan 2010 09:47:45 -0800 |
| |
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
| |