Re: [RFC] [PATCH 4/7] Uprobes Implementation

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

On Fri, 2010-01-15 at 19:50 +0530, Srikar Dronamraju wrote:
> > 
> > > > Furthermore it requires stopping and resuming tasks and nonsense like
> > > > that, that's unwanted in many cases, just run stuff from the trap site
> > > > and you're done.
> > > 
> > > I don't know what you mean exactly.  A trap already stopped task.
> > > utrace merely allows various clients to inspect/manipulate the state
> > > of the task at that moment.  It does not add any context switches or
> > > spurious stop/resumue operations.
> > 
> > Srikar seemed to suggest it needed stop/resume.
> > 
> 
> If process traps, We dont need to stop/resume other threads.
> uprobes needs threads to quiesce when inserting/deleting the breakpoint.
> 

Years ago, we had pre-utrace versions of uprobes where the uprobes
breakpoint-handler code was dispatched from the die_notifier, before the
int3 turned into a SIGTRAP.  I believe that's what Peter is
recommending.  On my old Pentium M...
- a pre-utrace uprobe hit cost about 1 usec;
- a utrace-based uprobe hit cost about 3 usec;
- and an unboosted kprobe hit cost 0.57 usec.

So yeah, learning about the int3 via utrace after the SIGTRAP gets
created adds some overhead to uprobes.  But as previously discussed in
this thread -- e.g.,
http://lkml.indiana.edu/hypermail/linux/kernel/1001.1/02969.html --
there are ways to avoid the 2nd (single-step) trap, which should cut
overhead in half.

Jim