From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19694 invoked by alias); 26 Apr 2011 02:44:26 -0000 Received: (qmail 19671 invoked by uid 22791); 26 Apr 2011 02:44:25 -0000 X-SWARE-Spam-Status: No, hits=-6.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,TW_GF,TW_OC,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; Tue, 26 Apr 2011 02:44:06 +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 p3Q2i4D8024524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 25 Apr 2011 22:44:04 -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 p3Q2i2Nb015605; Mon, 25 Apr 2011 22:44:03 -0400 Message-ID: <4DB63172.80705@redhat.com> Date: Tue, 26 Apr 2011 02:44: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: William Cohen , systemtap@sourceware.org Subject: Re: Linux VFS cache hit rate script References: <4DAF3D59.7020609@redhat.com> <4DB0B049.8070806@redhat.com> <4DB0C1AD.6080802@redhat.com> <4DB5FB66.8080600@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/msg00157.txt.bz2 On 04/25/2011 06:59 PM, Jake Maul wrote: > On Mon, Apr 25, 2011 at 3:53 PM, Josh Stone wrote: > >> I was thinking about what could be causing such high N/A counts, even on >> my nearly-idle laptop. I'm pretty sure now that these MAJOR==0 are >> actually "emulated" filesystems, like sysfs, procfs, etc. So I don't >> think the N/A has anything to do with caching - it's just that there's >> literally no block device associated with the request. > > Hmm, that would make a lot of sense. Can anyone verify this? Or, how > is it verifiable? I realized this when I did "lsof -c stapio", and I saw that the debugfs handles were on device 0,7. Then I did a systemwide lsof, and I could only see MAJOR==0 on procfs files, pipes, anon, etc. Plus it didn't make sense to me that the device parameters would have any idea whether things were cached. Even though you're looking in a return probe, the examination of the parameters is no different than in an entry probe. >> Some of the other probes in the vfs tapset deal with the page cache >> directly, which I think you'll need to get true vfs caching rates. > > Which probes are you thinking about? I see probes on when things get > added or removed from cache, but nothing jumps out at me as the ideal > way to see what was a hit or miss. It's less straightforward, but I think it can be done with a combo of probes. Something like this (untested): global pages, active global total_read, total_paged probe vfs.read { if (pid() != stp_pid()) active[tid()] = 1 } probe vfs.add_to_page_cache { if (active[tid()]) pages[tid()] += nrpages } probe vfs.read.return { if (active[tid()]) { total_read[pid(), tid(), execname()] <<< bytes_read total_paged[pid(), tid(), execname()] <<< pages[tid()] delete pages[tid()] delete active[tid()] } } probe end { foreach ([p,t,e] in total_read) printf("%5d %5d %16s read %d bytes, %d pages added\n", p, t, e, @sum(total_read[pid(), tid(), execname()]), @sum(total_paged[pid(), tid(), execname()])) } Problem is, I don't think you can tell this way how much of the new pages went toward this read, since you don't know how it was aligned. But in aggregate, it's probably pretty close. Josh