Re: [RFC] [PATCH] To improve kretprobe scalability
From: Abhishek Sagar
Date: Thu May 22 2008 - 08:16:31 EST
On 5/22/08, Srinivasa DS <srinivasa@xxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/