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