public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@qumranet.com>
To: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: akpm@linux-foundation.org, Ingo Molnar <mingo@elte.hu>,
	linux-kernel@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	kvm@vger.kernel.org
Subject: Re: [patch 0/4] Port KVM-trace to tracepoints
Date: Tue, 22 Jul 2008 21:42:56 +0300	[thread overview]
Message-ID: <48862A30.7050701@qumranet.com> (raw)
In-Reply-To: <20080717155724.897537670@polymtl.ca>

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),
>   (u32)((u64)kvm_register_read(vcpu, reg) >> 32),
>   handler);
>
> Sprinkled all across the KVM C code becomes :
>
> trace_kvm_cr_write(vcpu, cr, reg);
>
> Which looks much nicer, IMHO.
>
> It applies on top of linux-next patch-v2.6.26-next-20080715.
>
>   

It does look nicer; but it means maintaining tracepoints becomes much 
harder, because the information is scattered across many files.

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

The advantages I see to this are:

  - easy to add traces; the most important advantage
  - when the code changes, obsolete traces are completely removed
  - good performance
  - no need to have a formats file in userspace (which is tied to the 
kernel version)
  - can also send printk()s along, for synchronization with other kvm 
and kernel events

In fact, why not convert printk() to do this, making it a 
high-performance logging system?  Of course it would retain the dmesg 
interface, but we could say that messages at the KERN_TRACE level bypass 
dmesg and only go to the trace system.

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


  parent reply	other threads:[~2008-07-22 18:43 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-17 15:57 [patch 0/4] Port KVM-trace to tracepoints Mathieu Desnoyers
2008-07-17 15:57 ` [patch 1/4] kvm move VMCS Encodings to system headers Mathieu Desnoyers
2008-07-17 15:57 ` [patch 2/4] kvm move VMCS read " Mathieu Desnoyers
2008-07-17 15:57 ` [patch 3/4] KVM move register read-write " Mathieu Desnoyers
2008-07-17 15:57 ` [patch 4/4] KVM-trace port to tracepoints Mathieu Desnoyers
2008-07-17 16:49   ` Jan Kiszka
2008-07-17 17:28     ` Mathieu Desnoyers
2008-07-22 16:04       ` Jan Kiszka
2008-07-22 18:46         ` Avi Kivity
2008-07-23  7:49           ` Peter Zijlstra
2008-07-23  8:08             ` Avi Kivity
2008-07-23  8:55               ` Peter Zijlstra
2008-07-23  9:32                 ` Avi Kivity
2008-07-23  9:53                   ` Peter Zijlstra
2008-07-23 13:15                     ` Mathieu Desnoyers
2008-07-23 10:03                 ` Christoph Hellwig
2008-07-23 10:08                   ` Avi Kivity
2008-07-23 10:13                     ` Christoph Hellwig
2008-07-23 13:20               ` Mathieu Desnoyers
2008-07-17 16:52   ` Anthony Liguori
2008-07-17 17:04     ` Mathieu Desnoyers
2008-07-22 18:42 ` Avi Kivity [this message]
2008-07-22 19:16   ` [patch 0/4] Port KVM-trace " Frank Ch. Eigler
2008-07-22 19:31     ` Avi Kivity
2008-07-22 19:54       ` Frank Ch. Eigler
2008-07-22 22:12       ` [patch 0/4] Port KVM-trace to tracepoints -> LTTng ? Mathieu Desnoyers
2008-07-27 10:11         ` Avi Kivity
2008-07-28  0:54           ` [RFC] LTTng merge plan Mathieu Desnoyers
2008-07-29 16:18             ` Frank Ch. Eigler
2008-07-29 17:01               ` Mathieu Desnoyers
     [not found]                 ` <20080729211543.GB17097@redhat.com>
2008-07-29 22:41                   ` module-placed markers/tracepoints Mathieu Desnoyers
2008-07-29 23:01                     ` Frank Ch. Eigler
2008-07-29 23:19                       ` Mathieu Desnoyers
2008-07-30  1:40                     ` Rusty Russell
2008-07-30  2:27                       ` [PATCH] Module : call synchronize_sched() between module exit() and free Mathieu Desnoyers
2008-07-30  3:04                         ` Rusty Russell
2008-07-30  4:05                           ` Mathieu Desnoyers
2008-07-30 11:40                         ` Frank Ch. Eigler
2008-07-30 14:09                           ` Mathieu Desnoyers
2008-07-31  0:54                             ` Rusty Russell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48862A30.7050701@qumranet.com \
    --to=avi@qumranet.com \
    --cc=akpm@linux-foundation.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@polymtl.ca \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox