Messages in this thread | | | Date | Thu, 22 May 2008 17:46:19 +0530 | From | "Abhishek Sagar" <> | Subject | Re: [RFC] [PATCH] To improve kretprobe scalability |
| |
On 5/22/08, Srinivasa DS <srinivasa@in.ibm.com> wrote: > There were ideas of storing kretprobe instances in task_struct to get rid > of locking, but that would require extending task_struct
Wouldn't chaining of return instances in task_struct only increase its size by sizeof(struct list_head) bytes?
> and catching each task exit, destroying its kretprobe instances.
Which is kind of stil done by (...or at least we have a precendent of this issue's awareness) kprobe_flush_task().
> This makes code more invasive.
Ok.
> But in this implementation (global hash table, hashed by task), we > lock only the current task's hash bucket and hence we have fairly low > contention.
I may be underestimating the complexity of having returns instances associated with current task_struct, but anything else seems counter intuitive. There might be more possibilites to exploit the fact that functions instances are per-task.
A step in the right direction nevertheless :-)
> Thanks > Srinivasa DS -- Regards, Abhishek Sagar
| |