[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Prerna Saxena
Subject: Re: [Qemu-devel] [RFC 0/2] Tracing
Date: Fri, 21 May 2010 16:57:37 +0530
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100330 Fedora/3.0.4-1.fc11 Thunderbird/3.0.4

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


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.

Prerna Saxena

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]