This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug kprobes/2062] Return probes does not scale well on SMP box
- From: "jkenisto at us dot ibm dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sources dot redhat dot com
- Date: 19 Apr 2006 23:53:11 -0000
- Subject: [Bug kprobes/2062] Return probes does not scale well on SMP box
- References: <20051216010933.2062.anil.s.keshavamurthy@intel.com>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- Additional Comments From jkenisto at us dot ibm dot com 2006-04-19 23:53 -------
(In reply to comment #8)
> [snipped]
> > It is not a big deal, but some people might object that kprobes is touching
> > core kernel data structure like task struct...
> >
> perhaps it would be best to implement a new api that can be extended
> add one pointer (to a linked list) to the task struct that many
> projects can use as needed, so its just not for systemtap but any
> futrue project can use it as well...
Interesting idea. But in order for it to be useful for our particular purpose,
you'd have to be able to traverse the list without grabbing a lock. That puts
some potentially troublesome restrictions on how and when the list can be modified.
> > 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?
>
> there are 32 cocurrent thread machines availible today.. in less than
> 2 year dual 64 concurrent thread (128 thread) boxes will be availible
> on the market place you don't want to redesign this thing in 4 years
> do you?
What's your point here?
Thanks.
Jim
--
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.