This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug kprobes/2062] New: Return probes does not scale well on SMP box


> I did a through code review for return probes and found that even though
> return probes are built on top of kprobes which is highly parallel, 
> return probes does *not* run in parallel :-(. 
> 
> On an SMP box, when multiple target function on different 
> cpu's tickles into trampline_probe_handler(), 
> all those thread on different cpus are serialized 
> via big spin_lock_irqsave(&kretprobe_lock, ...).

[Jim] Correct.

> Can we do some thing here to make return probes run in 
> parallel on SMP box? Any thoughts?
[Jim]
Yes, I think we can probably make it so kretprobe handlers can run in
parallel.  Each task is responsible for recycling its own
kretprobe_instances, so I don't think we have to hold a lock all
throughout trampoline_probe_handler().  No other task is going to sneak
in and recycle our task's kretprobe_instances.

One possibly tricky part is unregistering.  unregister_kretprobe()
assumes that every kretprobe_instance is either on the kretprobe's free
list or its used (in-use) list.  (If it's on the free list, it's
immediately freed.  Otherwise, its kretprobe pointer is set to NULL and
trampoline_probe_handler() frees it when the probed function returns.)
There are a couple of places where a kretprobe_instance is sort of in
transition, and doesn't really belong on either list.
1. While ri->rp->handler is being run, you can't clobber ri->rp, because
the handler may be using it.
2. In (TBD) user-space return probes, when we enter the probed function,
there's a moment where we've verified that there's a free
kretprobe_instance available to us, but we haven't yet copied and
replaced the return address in user space (not really an issue on ppc64
where the return addtress is in a register)... and we can't be
absolutely (100.0000000%) sure that those user-space accesses will
succeed.

Perhaps adding a state variable to struct kretprobe_instance would help
here.

-- 
           Summary: Return probes does not scale well on SMP box
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: kprobes
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: anil dot s dot keshavamurthy at intel dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=2062

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]