[Bug translator/2293] confirm preemption/interrupt blocking in systemtap probes
Frank Ch. Eigler
fche@redhat.com
Fri May 5 16:38:00 GMT 2006
varap wrote:
> There is a generic problem that we have to solve in SystemTap to
> support long running or large number of probes. The common problem
> with these scenarios is, they generate lot more data than the maps
> can hold.
Let's turn the question around for a moment: how big arrays can we
safely support? What's the largest MAXMAPENTRIES people have tried?
> 1) We should have capability to say truncate the map by leaving only
> the top "n" entries based on the key. If one is looking to get
> general trends top few is more than enough hence this solution could
> be useful.
That's an interesting idea. Such a partial-delete operation would
have to be used carefully, since e.g. it destroys information that
could raise a low-ranked value from rising into the preserved few. In
other words, truncating periodically is not equivalent to truncating
once at the end.
> 2) Second solution is able to periodically dump the maps to
> userspace and then stpd during the post processing can reconstruct
> the full maps from the dumps. [...]
For "write-only" maps such as dtrace aggregates, this sort of thing
could work. In systemtap, all arrays are in general read/write, so
this would apply only in restricted cases and/or with moving some
processing over along with the data.
Ordinary trace data could of course be post-processed by user-space
scripts.
- FChE
More information about the Systemtap
mailing list