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

["jamesd dot wi at gmail dot com" <sourceware-bugzilla at sourceware dot org>]

------- Additional Comments From jamesd dot wi at gmail dot com  2006-04-18 19:32 -------
Subject: Re:  Return probes does not scale well on SMP box

On 18 Apr 2006 18:09:40 -0000, jkenisto at us dot ibm dot com
<sourceware-bugzilla@sourceware.org> wrote:
>
> ------- Additional Comments From jkenisto at us dot ibm dot com  2006-04-18 18:09 -------
> Created an attachment (id=974)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=974&action=view)
>  --> (http://sourceware.org/bugzilla/attachment.cgi?id=974&action=view)
> Thoughts on finer-grained locking for return probes
>
> I don't see how we can avoid significant lock overhead, because kretprobe data
> structures are much more dynamic that kprobe data structures: we're constantly
> moving kretprobe_instances back and forth between the kretprobe's free list and
> kretprobe_inst_table[].
>
> I've been thinking about this issue, though.  Attached are my current thoughts
> on finer-grained locking.
>

why not just store data per cpu/core, there is no way that two exit
probes can fire at the same time on the same cpu/core if you are in
the kernel and  inturupts are disabled. Then you just need one lock
for when you report the data from that cpus data structure. If a
return probe fires while someone else is accessing are data in the
cpu's structure we should give up and note the missed the probe fire
and return but this would be a very rare occurance in a properly
written script.

James Dickens
uadmin.blogspot.com

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


-- 


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.