This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Linux VFS cache hit rate script


On Mon, Apr 25, 2011 at 2:54 PM, Josh Stone <jistone@redhat.com> wrote:
> 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".

After: the only difference is which was commented out.

> 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

Will give this a try tomorrow.

> 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.

If it won't happen on more modern systems, I don't see a major problem
with ignoring it- it'll resolve itself. :)

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]