From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10240 invoked by alias); 18 Apr 2006 22:04:48 -0000 Received: (qmail 8151 invoked by uid 48); 18 Apr 2006 22:04:43 -0000 Date: Tue, 18 Apr 2006 22:04:00 -0000 Message-ID: <20060418220443.8135.qmail@sourceware.org> From: "jkenisto at us dot ibm dot com" To: systemtap@sources.redhat.com In-Reply-To: <20051216010933.2062.anil.s.keshavamurthy@intel.com> References: <20051216010933.2062.anil.s.keshavamurthy@intel.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug kprobes/2062] Return probes does not scale well on SMP box X-Bugzilla-Reason: AssignedTo Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2006-q2/txt/msg00182.txt.bz2 ------- Additional Comments From jkenisto at us dot ibm dot com 2006-04-18 22:04 ------- (In reply to comment #5) > > why not just store data per cpu/core > Storing it in per cpu might not work here as in some cases the function enter > might be called on one cpu and the by the time that function returns it could > have migrated to a different cpu's and hence return is executed from different > cpu. So we have to do global search for the return probe instance related to > that perticular task and hence per cpu/core is not feasible. Correct. I suppose we could enable the caller to promise that the probed function won't be preempted, won't sleep, and won't recurse, in which case we could allocate an array of per-cpu kretprobe_instances and avoid the locking associated with the free list. What that would look like in SystemTap, I don't know. And there's still the problem of the array of kretprobe_instances possibly having to stick around after unregister_kretprobe() returns and the kretprobe disappears. Can we manage that without a lock? > > However if we store the return probe instances in the task structure itself(by > extending the task struct)then we can completly eliminate the locks for return > probes and return probes can be made to run in parallel... Well, if we could add an hlist_head to struct task_struct (How big an "if" is that?), we could throw out kretprobe_inst_table[] and the locking around that. 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? I suppose we could avoid preallocating the kretprobe instances at all, and just allocate them as needed from GFP_ATOMIC space. :-} > > -Anil 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.