This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Better pagecache statistics ?
- From: "Frank Ch. Eigler" <fche at redhat dot com>
- To: Marcelo Tosatti <marcelo dot tosatti at cyclades dot com>
- Cc: systemtap at sources dot redhat dot com
- Date: Wed, 28 Dec 2005 16:13:14 -0500
- Subject: Re: Better pagecache statistics ?
- References: <1133377029.27824.90.camel@localhost.localdomain> <20051201152029.GA14499@dmt.cnet> <20051228013325.GA4144@dmt.cnet>
Hi -
> [...]
> a) nanosecond timekeeping
> Since the systemtap language does not support "struct" abstraction, but
> simply "long/string/array" types, there is no way to easily return more
> than one value from a function. Is it possible to pass references down
> to functions so as to return more than one value?
We don't support references (this enables stricter and simpler
checking), nor multiple return values (though we could - suggest a
good syntax for extracting tuple parts!).
> [...]
> For nanosecond timekeeping one needs second/nanosecond tuple (struct
> timespec).
Are you sure you need something beyond the 64-bit signed integers that
systemtap uses for all its numerics?
> b) ERROR: MAXACTION exceeded near identifier 'log' at ttfp_delay.stp:49:3
> The array size is capped to a maximum.
The MAXACTION limit is associated with code execution, not reserved
sizes for arrays (MAXMAPENTRIES ?). These values can be overridden
from the stap command line using -D.
> Is there any way to configure SystemTap to periodically
> dump-and-zero the arrays? This makes lots of sense to any
> statistical gathering code.
As mentioned in the other message, a script programmer can do this
with several kinds of explicit code.
> c) Hash tables It would be better to store the log entries in a hash
> table, the present script uses the "current" pointer as a key into a
> pair of arrays, [...]
Systemtap arrays *are* associative, and use hash tables. Consider
using the pid() or tgid() value to index into them.
> And finally, there seems to be a bug which results in _very_ large
> (several seconds) delays - that seems unlikely to really happening.
That is strange, though I recall hearing of vm problems that might
manifest themselves like that. Or maybe your "current"-pointer based
indexing is unintentionally colliding. Consider setting extra probe
points deeper down.
- FChE