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

["anil dot s dot keshavamurthy at intel dot com" <sourceware-bugzilla at sourceware dot org>]

------- Additional Comments From anil dot s dot keshavamurthy at intel dot com  2006-04-18 23:48 -------
> 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.

Asking probed function not to preempt or sleep won;t work as we will be left 
with no return probes on most of the kernel functions.


> 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?

We can not avoid the lock if return probe instance (ri) is managed either 
globally or on per_cpu queue since may tasks will be running in parallel.

> > 
> > 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. 
It is not a big deal, but some people might object that kprobes is touching 
core kernel data structure like task struct. Not sure about the penalty of 
this extra space in task struct. We need to submit a patch and see what 
community has to say.

> 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?

Having to allocate per-task pool would be very expensive, as every task that 
gets created will have to allocat the memory and release it when the task is 
dead no matter the retprobe gets fired or not.

I guess at the first step, it should be okay to have the lock in the kretprobe 
prepare stage(since other than moving the kretprobe instance from free list to 
used list, we don;t do much holding the lock)

> I suppose we could avoid preallocating the kretprobe instances at all, and 
just
> allocate them as needed from GFP_ATOMIC space. :-}
This could be other alternative, we can try this one too.


-Anil


-- 


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.