Mathieu Desnoyers wrote:
Yes, but the userspace side would collect the format strings as well (just
once) and could put them in the same file. The aggregation is portable
across kernel versions.
Yes,
LTTng does exactly all that.
[snip goodies]
I'll be more than happy to
Mathieu Desnoyers wrote:
Hi,
Here is a port of KVM-trace, currently using macros on top of the Linux Markers,
to tracepoints. Note that I cleaned up the instrumentation too, so stuff like
KVMTRACE_3D(CR_WRITE, vcpu, (u32)cr,
(u32)kvm_register_read(vcpu, reg),
Avi Kivity [EMAIL PROTECTED] writes:
[...]
kvm tracepoints are heavily tied into the implementation; and making
them harder to write means we will have less information. In fact, I
am contemplating moving in another direction (when looking at the
pgprintk()s scattered around
Frank Ch. Eigler wrote:
Avi Kivity [EMAIL PROTECTED] writes:
[...]
kvm tracepoints are heavily tied into the implementation; and making
them harder to write means we will have less information. In fact, I
am contemplating moving in another direction (when looking at the
pgprintk()s
Avi Kivity [EMAIL PROTECTED] writes:
[...]
Have you considered using trace_mark() directly - eliminating the
KVM_TRACEN() middlemen?
[...]
Using trace_mark() directly -- looking at it, seems to fit the
requirements exactly. Should have looked at it earlier. Is there a
way to get a list
* Avi Kivity ([EMAIL PROTECTED]) wrote:
Frank Ch. Eigler wrote:
Avi Kivity [EMAIL PROTECTED] writes:
[...]
kvm tracepoints are heavily tied into the implementation; and making
them harder to write means we will have less information. In fact, I
am contemplating moving in another
Hi,
Here is a port of KVM-trace, currently using macros on top of the Linux Markers,
to tracepoints. Note that I cleaned up the instrumentation too, so stuff like
KVMTRACE_3D(CR_WRITE, vcpu, (u32)cr,
(u32)kvm_register_read(vcpu, reg),
(u32)((u64)kvm_register_read(vcpu, reg) 32),
handler);
