Ingo Molnar wrote:
KVMTRACE_3D(MSR_READ, &svm->vcpu, ecx, (u32)data,
(u32)(data >> 32), handler);
after:
kvm_trace("MSR_READ: %p, %08lx, %016Lx\n", &svm->vcpu, ecx, data);
As a result all these traces would become a lot more readable
(and a lot more flexible) both in the source code, and in the
trace output stage.
And any ad-hoc tracepoint can be added, without worrying about
the name of the macro or the number of type of arguments. Note
that in this specific example we didnt need to split up the u64
'data' into two 32-bit values, nor do we have to pass in the
'handler' name, nor do we have to provide a MSR_READ
enumeration.
The tracing-disabled case would still be as fast - a single
branch check.
Avi, what do you think, any objections against an RFC patchset
that shows this off?
Definitely, as long as formatting is performed after the data is
gathered (say, in userspace). kvmtrace can generate around 1M
events/sec/cpu, so we need truly low overhead.
--
error compiling committee.c: too many arguments to function
--
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
