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

[Frank Ch. Eigler]

Ingo Molnar <mingo@xxxxxxx> writes:

> [...]
> there's i think the KVM usecase where markers are used 
> essentially a printk()-alike flexible tracing facility.
>
> [...]
> ./vmx.c:	KVMTRACE_3D(MSR_READ, vcpu, ecx, (u32)data, (u32)(data >> 32),
> ./vmx.c:	KVMTRACE_3D(MSR_WRITE, vcpu, ecx, (u32)data, (u32)(data >> 32),
> ./vmx.c:	KVMTRACE_0D(PEND_INTR, vcpu, handler);
>
> I think this could easily be converted to a wrapper around 
> ftrace_printk() plus a "kvmtrace" ftrace plugin [...]

It would be even easier converted to the markers API directly,
without the KVMTRACE* macro intermediary:

before:
        KVMTRACE_3D(MSR_READ, &svm->vcpu, ecx, (u32)data,
                    (u32)(data >> 32), handler);
after:
	trace_mark(kvmtrace, "MSR_READ: %p, %08lx, %016Lx\n",
                             &svm->vcpu, ecx, data);

All this already "just works".

The only part that's missing, from ftrace's point of view, is an
interface from markers to the ftrace printing.  And Lai Jiangshan
kindly posted exactly such generic code back in December:

http://lkml.org/lkml/2008/12/30/297

Please let's get this merged.

> This means KVM tracing is activated via:
>  echo kvmtrace > /debug/tracing/current_tracer
> that's all.

Lai's interface is almost identical, and automatically works for
any/all markers.


> And any ad-hoc tracepoint can be added, without worrying about 
> the name of the macro or the number of type of arguments. [...]

(This KVMTRACE stuff was always unnecessary with respect to markers,
and must have been explained by some historical baggage.)


- FChE
--
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/