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

From: Mathieu Desnoyers
Date: Tue Jul 22 2008 - 18:12:32 EST

* Avi Kivity (avi@xxxxxxxxxxxx) wrote:
> 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.


LTTng does exactly all that.

Please have a look at the current LTTng patchset :

The interface to list markers is currently found in /proc/ltt

Commands like :

cat /proc/ltt (list markers)
And echo -n "connect marker_name default dynamic channel_name"

See the script in the package :

To see how to arm all markers listed.

General information (compatibility list and quickstart guide are
available at Packages also useful : lttv (trace
analyser, including text dump, filtering, gui...) and a userspace marker
package (only supports x86 32/64 currently).

All these packages support any kind of custom markers, because the
marker names/types are listed in the "facilities_*" control tracefile at
trace start, so the traces are self-described. I also list other stuff
(memory maps, irq handler names, system call handler names) at trace
start so we can dynamically have these mapping, independently of the

See :

I'll be more than happy to answer your questions.


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

Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at