Cc: Mathieu Desnoyers <mathieu.desnoyers@...>, LKML <linux-kernel@...>, Ingo Molnar <mingo@...>, Linus Torvalds <torvalds@...>, Andrew Morton <akpm@...>, Peter Zijlstra <a.p.zijlstra@...>, Christoph Hellwig <hch@...>, Gregory Haskins <ghaskins@...>, Arnaldo Carvalho de Melo <acme@...>, Thomas Gleixner <tglx@...>, Tim Bird <tim.bird@...>, Sam Ravnborg <sam@...>, Frank Ch. Eigler <fche@...>, Steven Rostedt <srostedt@...>, Paul Mackerras <paulus@...>, Daniel Walker <dwalker@...>
Hi -
On Thu, Jan 17, 2008 at 03:08:33PM -0500, Steven Rostedt wrote:
If you find yourself wanting to perform computations like finding
maxima, or responding right there as opposed to later during userspace
trace data extraction, then you're trending toward a tool like
systemtap.
Yes, more self-contained marker events are necessary for meaningful
in-situ processing. That needs to be balanced by the increased cost
for computing and passing the extra parameters, multiplied the event
occurrence rate.
In this case, the prev/next pointers are sufficient to compute the
other values. For particularly performance-critical markers, it may
not be unreasonable to expect the callback functions to dereference
such pointers for pretty-printing or other processing.
This \0 hack is perhaps too clever. Much of the cost of the extra
parameters is already paid by the time that a simpleminded tracing
callback function starts going through the string. Also, I believe
the systemtap marker interface would break if the format strings were
not singly terminated ordinary strings.
- FChE
--
