Re: [patch 0/4] Port KVM-trace to tracepoints

From: Avi Kivity
Date: Tue Jul 22 2008 - 15:32:55 EST


Frank Ch. Eigler wrote:
Avi Kivity <avi@xxxxxxxxxxxx> 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 arch/x86/kvm/mmu.c:

kvm_trace("pfentry", "page_fault entry addr %lx error code %x\n",
cr2, error_code);

Unlike printk()s, no actual formatting would occur during runtime.

Have you considered using trace_mark() directly - eliminating the
KVM_TRACEN() middlemen?


Eliminating KVM_TRACEN -- yes. There are too many of them, they aren't type-aware, and they're in uppercase.

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 of all markers?

Perhaps the kvmtrace marker->relay integration should be made a marker feature, since there is nothing specific to kvm in it.

Instead, at initialization time all the strings would be parsed into
a data structure that describes the data types, and the runtime
would simply consult this structure and copy the arguments into
trace records. User space would also be able to pull this structure
and so recreate the formatted string.

If one really wanted to, one could build such a mechanism on top of
marker-based callbacks.


One does want to.

- no need to have a formats file in userspace (which is tied to the
kernel version)

OTOH, you'd have the kernel collecting compact binary records
containing just the parameters, which are at least as tied to kernel
version.


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.

--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

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