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: Better pagecache statistics ?


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


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