From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25942 invoked by alias); 25 Apr 2011 21:54:55 -0000 Received: (qmail 25916 invoked by uid 22791); 25 Apr 2011 21:54:51 -0000 X-SWARE-Spam-Status: No, hits=-6.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 25 Apr 2011 21:54:34 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p3PLsWhE012619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 25 Apr 2011 17:54:32 -0400 Received: from [10.3.113.81] (ovpn-113-81.phx2.redhat.com [10.3.113.81]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p3PLsW1X008262; Mon, 25 Apr 2011 17:54:32 -0400 Message-ID: <4DB5ED98.7070207@redhat.com> Date: Mon, 25 Apr 2011 21:54:00 -0000 From: Josh Stone User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.9 MIME-Version: 1.0 To: Jake Maul CC: systemtap@sourceware.org Subject: Re: Linux VFS cache hit rate script References: <4DAF3D59.7020609@redhat.com> <4DB0B049.8070806@redhat.com> <4DB0C1AD.6080802@redhat.com> <4DB1E4D2.70200@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 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: 2011-q2/txt/msg00153.txt.bz2 On 04/22/2011 02:47 PM, Jake Maul wrote: > Here's an interesting note though: the line numbers are different. The > only difference between the runs is which of the 2 functions is > commented out. > > With stock function: > ERROR: Array overflow, check MAXMAPENTRIES near identifier '$file' at > /usr/share/systemtap/tapset/vfs.stp:769:9 > > With your function: > ERROR: Array overflow, check MAXMAPENTRIES near identifier '$file' at > /usr/share/systemtap/tapset/vfs.stp:780:9 Was the "stock" one before you added my new version of the function? I think that would easily explain why the line numbers got shifted. Note that both are talking about $file at column 9, which in your snippet only makes sense for the "file = $file". Anyway, I just realized that there is a way that $file could actually be involved with a map overflow (which I thought was wrong before). When accessing parameters in a .return probe, we first use an entry probe to save the value into a map, then read that back in the actual .return probe. So that saving map could be the thing that is overflowing. I notice that you also have a bunch of skipped probes, which is probably due to not enough kretprobe slots available. (-t can tell for sure.) I think this may be causing a bug that sometimes the saved $file is not being cleared, because the part that would use it is getting skipped. Your 2035 skipped seems not enough to accumulate past the default 10,000 MAXMAPENTRIES, but I don't have other ideas. I would suggest tweaking KRETACTIVE until there's no skipping, as described here: http://sourceware.org/systemtap/wiki/TipSkippedProbes I'm not sure there's a way we could more cleanly fail this case of skipped probe vs. stale saved $var. On kernels since 2.6.25 we actually use a different saving mechanism though, which wouldn't have the same mapping problem. > Side note: I wonder if the "name" variables are messed up... vfs.read* > and vfs.write* don't follow quite the same pattern: > > probe vfs.read = kernel.function("vfs_read") > name = "vfs.read" > probe vfs.read.return = kernel.function("vfs_read").return > name = "vfs.read" > probe vfs.readv = kernel.function("vfs_readv") > name = "vfs.read" > probe vfs.readv.return = kernel.function("vfs_readv").return > name = "vfs.readv" Yeah, looks like a typo - the third should probably be readv. Josh