Re: [Qemu-devel] [RFC 0/2] Tracing

[Prerna Saxena <prerna@linux.vnet.ibm.com>]

Hi Stefan,

Nice to see the patchset.
I am working on something similar, on the lines of static trace events 
for QEMU, that collect traces in a qemu-internal buffer. This would 
employ monitor commands to read traces, as well as enable/disable trace 
events at runtime.
I plan to post a prototype early next week.

On 05/21/2010 03:12 PM, Stefan Hajnoczi wrote:
> Trace events in QEMU/KVM can be very useful for debugging and performance
> analysis.  I'd like to discuss tracing support and hope others have an interest
> in this feature, too.
>
> Following this email are patches I am using to debug virtio-blk and storage.
> The patches provide trivial tracing support, but they don't address the details
> of real tracing tools: enabling/disabling events at runtime, no overhead for
> disabled events, multithreading support, etc.
>
> It would be nice to have userland tracing facilities that work out-of-the-box
> on production systems.  Unfortunately, I'm not aware of any such facilities out
> there right now on Linux.  Perhaps SystemTap userspace tracing is the way to
> go, has anyone tried it with KVM?
>
> For the medium term, without userspace tracing facilities in the OS we could
> put something into QEMU to address the need for tracing.  Here are my thoughts
> on fleshing out the tracing patch I have posted:
>
> 1. Make it possible to enable/disable events at runtime.  Users enable only the
>     events they are interested in and aren't flooded with trace data for all
>     other events.
>

Agree, my upcoming patchset should address this.

> 2. Either make trace events cheap or build without trace events by default.
>     Disable by default still allows tracing to be used for development but
>     less for production.
>

I'm trying to do this too, though quite a lot remains to be improved in 
my current implementation :-)

> 3. Allow events in any execution context (cpu, io, aio emulation threads).
>

Agree.

> 4. Make it easy to add new events.

Agree ! I'm trying to provide a unified macro interface like trace 
events which makes it easy enough to add new events.


Regards,
-- 
Prerna Saxena

Linux Technology Centre,
IBM Systems and Technology Lab,
Bangalore, India