lkml.org 
[lkml]   [2008]   [May]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2008-05-22 14:19    [W:0.038 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site