This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug kprobes/2062] New: Return probes does not scale well on SMP box
- From: "anil dot s dot keshavamurthy at intel dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sources dot redhat dot com
- Date: 16 Dec 2005 01:09:34 -0000
- Subject: [Bug kprobes/2062] New: Return probes does not scale well on SMP box
- Reply-to: sourceware-bugzilla at sourceware dot org
> 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.