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

["jkenisto at us dot ibm dot com" <sourceware-bugzilla at sourceware dot org>]

------- Additional Comments From jkenisto at us dot ibm dot com  2006-04-18 22:04 -------
(In reply to comment #5)
> > why not just store data per cpu/core
> Storing it in per cpu might not work here as in some cases the function enter 
> might be called on one cpu and the by the time that function returns it could 
> have migrated to a different cpu's and hence return is executed from different 
> cpu. So we have to do global search for the return probe instance related to 
> that perticular task and hence per cpu/core is not feasible.

Correct.  I suppose we could enable the caller to promise that the probed
function won't be preempted, won't sleep, and won't recurse, in which case we
could allocate an array of per-cpu kretprobe_instances and avoid the locking
associated with the free list.  What that would look like in SystemTap, I don't
know.

And there's still the problem of the array of kretprobe_instances possibly
having to stick around after unregister_kretprobe() returns and the kretprobe
disappears.  Can we manage that without a lock?

> 
> However if we store the return probe instances in the task structure itself(by 
> extending the task struct)then we can completly eliminate the locks for return 
> probes and return probes can be made to run in parallel...

Well, if we could add an hlist_head to struct task_struct (How big an "if" is
that?), we could throw out kretprobe_inst_table[] and the locking around that. 
But do you also envision a per-task pool of kretprobe_instances?  If so, how
big?  If not, aren't we back to locking some sort of free list, at least for the
sleeping and/or recursive functions?

I suppose we could avoid preallocating the kretprobe instances at all, and just
allocate them as needed from GFP_ATOMIC space. :-}

> 
> -Anil

Jim



-- 


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.