Having one value for MAXACTION applied to kprobe events, timer events and begin and end probes does not work well. To do time-consuming operations in an end probe, you must boost MAXACTION to a very high value, which allows those same time-consuming operations to be done in a kprobe. This is a big safety problem. I suggest having MAXACTION set to a very high value (just high enough to eliminate infinite loops) in begin and end probes. Timer events should likely be a higher value than for kprobes, although how much needs investigated.
Please suggest alternate sets of limits, and investigate their implications.
Looking at how the translator implements timers, I see it is using kernel timers, which run in interrupt context using softirqs. A far better choice would be to implement them using work queues, which run in process context. If we do this, begin, end, and timer probes should have MAXACTION set to a very high number, like 1000000. The exact numbers can be fine-tuned later.
*** Bug 1866 has been marked as a duplicate of this bug. ***
The choice of user vs interrupt context is not too relevant to the maximum reasonable MAXACTION count. Probes still are supposed to run atomically (unpreempted, uninterrupted) for safety reasons. (Whether this may be relaxed somewhat is a separate question for the future.) Spending 1 million systemtap statements in an unpreemptable kernel routine could put even a fast machine to sleep for a big fraction of a second, which is almost certainly too long. One way to resolve this is to set a target time limit, say 5 ms, then work backward to a representative MAXACTION number. Maybe we could run our own stap-o-mips measurement at startup and tune the number automagically.
This is partly done for begin/end probes, and suggests a framework for experimenting with such changes for other probe types. *** This bug has been marked as a duplicate of 4146 ***