From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15743 invoked by alias); 14 Nov 2006 20:00:35 -0000 Received: (qmail 15720 invoked by uid 22791); 14 Nov 2006 20:00:29 -0000 X-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 14 Nov 2006 20:00:18 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id kAEK0FKk009462; Tue, 14 Nov 2006 15:00:15 -0500 Received: from pobox.hsv.redhat.com (pobox.hsv.redhat.com [172.16.16.12]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id kAEK0FWT013909; Tue, 14 Nov 2006 15:00:15 -0500 Received: from [172.16.17.170] (dhcp-170.hsv.redhat.com [172.16.17.170]) by pobox.hsv.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id kAEK0E7C025201; Tue, 14 Nov 2006 15:00:14 -0500 Message-ID: <455A2006.5010808@redhat.com> Date: Tue, 14 Nov 2006 20:16:00 -0000 From: David Smith User-Agent: Thunderbird 1.5.0.8 (X11/20061107) MIME-Version: 1.0 To: David Wilder CC: Systemtap List Subject: Re: S390x - REL5 stap_testing_200611132049.results] References: <45590329.5080606@us.ibm.com> <4559BAFB.8010008@redhat.com> <4559F3FD.1000206@us.ibm.com> <4559F558.6010108@redhat.com> <455A14E2.3020901@us.ibm.com> <455A17EC.8090002@redhat.com> <455A259E.5040505@us.ibm.com> In-Reply-To: <455A259E.5040505@us.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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-q4/txt/msg00430.txt.bz2 David Wilder wrote: > David Smith wrote: >> Hmm. It appears from that output that the 'stap' binary you are using >> doesn't have caching support. If it did, the name of the C file >> wouldn't be 'stap_9388.c', it would be something like >> 'stap_6bc3d92354bbb164201d174128e2eca5_122.c'. >> >> Can you check and ensure that the latest systemtap has been compiled >> and installed? Let's see the output of "stap -V". >> > Woops, I thought I had run make install, I guess not. Here is the > output running the current version of stap. > > [root@hez235 obj]# ./stap -v -p4 -e "probe begin {}" > Pass 1: parsed user script and 52 library script(s) in > 5740usr/130sys/6472real ms. > Pass 2: analyzed script: 1 probe(s), 0 function(s), 0 embed(s), 0 > global(s) in 80usr/0sys/102real ms. > Pass 3: translated to C into > "/tmp/stapMeHOHh/stap_f087f4375cd915e8f124ba8ee388fbb9_177.c" in > 10usr/10sys/2real ms. > Pass 4: compiled C into "stap_f087f4375cd915e8f124ba8ee388fbb9_177.ko" > in 7580usr/1360sys/10365real ms. > [root@hez235 obj]# ./stap -v -p4 -e "probe begin {}" > Pass 1: parsed user script and 52 library script(s) in > 5720usr/130sys/6756real ms. > Pass 2: analyzed script: 1 probe(s), 0 function(s), 0 embed(s), 0 > global(s) in 90usr/10sys/97real ms. > Pass 3: using cached > /root/.systemtap/cache/f0/stap_f087f4375cd915e8f124ba8ee388fbb9_177.c > Pass 4: using cached > /root/.systemtap/cache/f0/stap_f087f4375cd915e8f124ba8ee388fbb9_177.ko Great. Now it looks like basic caching functionality is working for you. > Looks better, But I still needed to comment out the extra defines for > _stp_free_percpu() in alloc.c. You might want to try a "make install" with an unmodified alloc.c just to see if the real problem was with mismatches between old/new stap, tapsets, and runtime. -- David Smith dsmith@redhat.com Red Hat http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax)