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: MAXACTION exceeded error while using systemtap


Hi -

> I think that SystemTap needs some method to periodically (or when
> memory pressure arrives) dump the parts of the array to userspace
> via relayfs. [...]

There are two separate issues here: data transfer to user space, and
the production of that data.

For purposes of transfer, systemtap can stream to userspace using
relayfs or procfs buffers.  The choice of channel is picked at
translation time with an option to the stap(1) program.

The production of that data is to me a more interesting issue.  As
systemtap was designed to support purposes well beyond simple dumping
of bulk trace data, it does not consider trace collection into
automagically drained buffer arrays as its primitive.  Rather, it
provides means for a script programmer to accumulate, derive
information, perform filtering/aggregation/analysis, and when/if
necessary, send ultimately interesting results to userspace.

So, the next question is how one would best emulate the LTT style of
buffered tracing with this more expressive system.  One approach is
what is already demonstrated with some of our scripts - to have
timer-based script routines that sort/dump/clear array pieces.  Of
course, one could also perform this sort/dump/clear idiom right inline
with data collection points, or within a handler of a hypothetical new
"this systemtap array memory is running low" event.  Or one could
enqueue trace data right to the output stream (call "printf"), not
accumulating any within systemtap arrays, and then use userspace
postprocessing scripts to do the analysis.

So, there are lots of options.

- FChE


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