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
> 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 ltt-armall.sh in the package :
To see how to arm all markers listed.
General information (compatibility list and quickstart guide are
available at http://ltt.polymtl.ca). 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
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.
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/