Re: Linux VFS cache hit rate script

[Josh Stone <jistone@redhat.com>]

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 "<TAB>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