From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19868 invoked by alias); 13 Jul 2006 19:44:10 -0000 Received: (qmail 19831 invoked by uid 48); 13 Jul 2006 19:44:02 -0000 Date: Thu, 13 Jul 2006 19:44:00 -0000 Message-ID: <20060713194402.19830.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-q3/txt/msg00091.txt.bz2 ------- Additional Comments From jkenisto at us dot ibm dot com 2006-07-13 19:44 ------- (In reply to comment #19) > ====== 2.6.17.3/ppc64/8-way, without Jim's patch ================ > > no probe > Total cpus: loops = 40000000, average = 6202 ns > > kretprobe using stap: > Total cpus: loops = 40000000, average = 43702 ns > > kretprobe using getsid.c: > Total cpus: loops = 40000000, average = 36456 ns > > > ======= 2.6.17.4/ppc64/8-way, with Jim's patch =================== > > kretprobe using stap: > Total cpus: loops = 40000000, average = 26621 ns > > kretprobe using getsid.c: > Total cpus: loops = 40000000, average = 24975 ns This is actually pretty much what I'd expect to see. All the CPUs are hitting the same probepoint repeatedly and piling up on the same per-kretprobe lock. But the performance gain is reasonably good, and even better when stap's involved. The stap-generated handler takes longer than the empty kprobes handler, so we get more benefit from not holding a lock while the handler runs. We should see more benefit with multiple kretprobes -- e.g. probe syscall.*.return { ... } Keep the comments and improvements coming. Thanks. -- 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.