[lkml]   [2009]   [Feb]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] tracing/markers: make markers select tracepoints
Ingo Molnar <> 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:

KVMTRACE_3D(MSR_READ, &svm->vcpu, ecx, (u32)data,
(u32)(data >> 32), handler);
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:

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

 \ /
  Last update: 2009-02-21 23:07    [W:0.061 / U:1.900 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site