Re: MAXACTION exceeded error while using systemtap

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

Hi -


hunt wrote:

> What I would like to see is MAXACTION set to a very low value in
> kprobes (or jprobes or djprobes). It would be equivalent to a couple
> of milliseconds, at most.

Could someone undertake an experiment to measure how long some
representative probes actually take?  If it turns out that we can fit
10**4 or even 10**5 "typical" systemtap statements within a small
amount of wall-clock time on a typical machine, then MAXACTION could
simply be bumped up to that number.

The current default MAXACTION value (1000) was picked within the
confines of the same data vacuum that we have within this discussion.


> It would prevent things like sorting and printing maps, no matter
> what their size. Theoretically we could allow these for very small
> maps, but why would we want to?

Well, because they may be necessary for some as-yet-unimagined probing
context.  The problem is not sorting per se, but the amount of time
that sorting (or anything else) takes.  If we were to impose
language-level restrictions, and someone still needed to sort/print
array pieces from within a kprobe, they'd just work around it.  They
can go and open-code a bubble sort in script language, a foreach/print
over the array.  I'm sure you agree this is not desirable.


> Rather than attempt to calculate how much time a potentially
> time-consuming function will really take [...]

I'm not suggesting that such a calculation need be precise enough to
be anything more than a trivial function of the subject map size.  It
just needs to be vaguely proportional to the cost, so we can keep to a
rough deadline.


> For timer events, MAXACTION would be very large. Large enough to
> sort any size arrays and print maybe 1000 lines or so.  For begin
> and end probes, MAXACTION would be something less than infinite so
> there are no infinite loops.

I believe this expresses the mistaken belief that deadlines are only
necessary for kprobes.


- FChE