Re: [PATCH] tracing/markers: make markers select tracepoints

Frank Ch. Eigler
2009-02-23T15:44:37Z

Hi -

On Mon, Feb 23, 2009 at 12:11:27PM +0100, Peter Zijlstra wrote:
> [...]
> > > Because after a printk() debug spree, I don't commit them, I toss them
> > > out and keep the fix.
> >
> > Markers solve a problem closer to tracepoints than to debugging
> > printk's.

> Not so. In both cases the regular stuff (NMI trace, OOPS,
> function/graph/sched trace, etc) is not enough and you wish to
> augment its output.

Sorry, I don't see how that relates. If the general function tracing
widgetry is insufficient for some subsystem/purpose, some sort of
static instrumentation is needed. Whether that instrumentation is
done by markers (with a thin glue to ftrace) or by tracepoints (with a
thick glue to ftrace) doesn't change the need for "augmentation".

> > In this context, the main difference between tracepoints is that
> > markers need almost no hand-written glue code of the sort that make up
> > ftrace engines that just trace simple values. Simpler & smaller code
> > for the same output seems like a win.
>
> Right, for dumb tracers that's true I suppose, however any
> high-bandwidth tracer will try to avoid putting silly ASCII strings in
> and will therefore need to write more glue code.

So let's leave it up to the wisdom of each subsystem maintainer to
decide whether any particular trace event is high enough throughput
that direct ASCII rendering is not favourable. (Considering the
finite size of tracing buffers, high-throughput trace events would
need to be continually drained with ASCII conversion anyway, so the
overall benefit of using packed binary as an intermediate copy may not
be large after all.)

I see all this as an argument to keep the subsystem's options open.
Sometimes the extra complexity of tracepoints is worth it, sometimes
it isn't.

- FChE