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

[Peter Zijlstra]

On Mon, 2009-02-23 at 10:44 -0500, Frank Ch. Eigler wrote:
> 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".

I'm not arguing against static instrumentation per-se (although
expanding the coverage of dynamic/automatic instrumentation is much more
profitable IMHO).

What I'm arguing is that trace_mark()s one distinguishing feature over
tracepoints is only suited for quick debug like work.

Furthermore, trace_mark() exposes that crap like an ABI, now suppose
some distro goes and declares that stable for some daft reason, imagine
the poor sod having to fix something littered with trace_mark().

Look at fs/ext4/ for a particularly horrid example.

[ quite apart from why I hate trace_mark() most -- which is that it
makes the code look like someone committed their tree after a debugging
session ]

> > > 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.

It always is, either the information is useful, or it isn't. If it isn't
we shouldn't have it in tree. If it is, you never know how people will
want to use it.

Big but low-rate events will take space that could have been properly
used to capture longer - giving a better view of subsystem interaction.

Tracing transcends sub-systems in that sense, its not about
per-subsystem tracers, its about full overview, and whilst subsystem
maintainers can help in determining what information is useful,
presenting that information in big bloated blobs is beyond that scope.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/