This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Linux VFS cache hit rate script
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