From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31463 invoked by alias); 14 May 2009 15:11:15 -0000 Received: (qmail 31454 invoked by uid 22791); 14 May 2009 15:11:13 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 14 May 2009 15:10:59 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n4EFAwtk021547; Thu, 14 May 2009 11:10:58 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n4EFAvSh027033; Thu, 14 May 2009 11:10:57 -0400 Received: from localhost.localdomain (dst61.hsv.redhat.com [172.16.16.175]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n4EFArKD019157; Thu, 14 May 2009 11:10:55 -0400 Message-ID: <4A0C347D.9060204@redhat.com> Date: Thu, 14 May 2009 15:11:00 -0000 From: David Smith User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Roland McGrath CC: Maynard Johnson , systemtap@sourceware.org, "Frank Ch. Eigler" Subject: Re: Backward compatibility for insn probe point References: <49D3E3DF.1000108@us.ibm.com> <49F61D09.8090503@redhat.com> <49F8C1C0.8070208@us.ibm.com> <49F9E71D.2070500@redhat.com> <20090430203302.5FFA0FC3BF@magilla.sf.frob.com> <4A099E6B.8090501@redhat.com> <20090512181950.19BCCFC35D@magilla.sf.frob.com> <4A0AE179.9050801@redhat.com> <20090513182359.0CF33FC35D@magilla.sf.frob.com> In-Reply-To: <20090513182359.0CF33FC35D@magilla.sf.frob.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2009-q2/txt/msg00581.txt.bz2 Roland McGrath wrote: >> I poked around the kernel source some more, but couldn't see what was >> going wrong. > > I figured you'd use some stap probes to follow the code paths! Oh I did, but so much of it is inlined that it was incredibly difficult to follow. >> I've changed the itrace code to stop the task after each step trap (so >> that it acts more like ptrace). I've tested this on several kernels >> (2.6.18-141.el5/ppc, 2.6.18-128.1.10.el5/x86_64/i686, and >> 2.6.25-14.fc9.ppc64) and it seems to work correctly. >> >> Does this seem like a reasonable work-around? Could there be problems >> with this approach? > > I presume it kills performance. But what works works, that's a what a > work-around is. I'd hope that you don't make it use this "not really > right" mode for kernels with the modern utrace interface that doesn't have > this bug. Yes, this is only for old utrace. As far as performance goes, I've benchmarked single-stepping '/bin/ls' on x86_64 with both approaches. Here's what I saw ('time' output, averages of 5 runs): - no stopping on each step trap: real 0m3.735s user 0m0.328s sys 0m3.359s - stopping on each step trap: real 0m4.101s user 0m0.336s sys 0m3.692s I could also limit this work-around to ppc-only, to not penalize other architectures. One last thing. I thought I'd try block stepping, so I got access to an ia64 machine. Unfortunately, using systemtap insn probes (either single or block step) lock up the system with a spinlock lockup. Sigh. -- David Smith dsmith@redhat.com Red Hat http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax)