Re: Linux VFS cache hit rate script

[Josh Stone <jistone at redhat dot com>]

On 04/25/2011 06:59 PM, Jake Maul wrote:
> On Mon, Apr 25, 2011 at 3:53 PM, Josh Stone <jistone@redhat.com> 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