Re: [Bug translator/2293] confirm preemption/interrupt blocking in systemtap probes

["Frank Ch. Eigler" <fche at redhat dot com>]

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