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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
