qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 00/14] trace: Add static tracing to QEMU


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH 00/14] trace: Add static tracing to QEMU
Date: Fri, 13 Aug 2010 14:45:48 +0100

On Thu, Aug 12, 2010 at 7:10 PM, Blue Swirl <address@hidden> wrote:
> On Thu, Aug 12, 2010 at 10:36 AM, Stefan Hajnoczi
> <address@hidden> wrote:
>> This patch series adds static tracing to QEMU.  It can be used to instrument
>> QEMU code by means of lightweight logging called trace events.
>>
>> Prerna and I are now posting the entire patch series with a serious eye 
>> towards
>> checking we meet users' and developers' tracing needs and with the goal of
>> getting this functionality merged into qemu.git.
>
> I sent a few comments about some patches, others looked fine to me.

I appreciate your reviews!  Thank you.

Two outstanding issues that I'd like to discuss:

1. Writing the trace buffer is currently synchronous - fwrite(3) is
used by the unlucky caller that fills up the trace buffer.  Ideally
traces should never block and write-out would be asynchronous.  With a
regular file I'm not sure how much of an issue this is to performance,
since the kernel could copy the trace buffer to the page cache and
write it out sometime later.  I've avoided adding a dedicated thread
because it will make the code more complex - any thoughts?

2. The timestamping code uses clock_gettime() and will not build on
Windows.  I'd like to reuse qemu-timer.c but there are two issues.
First, calling QEMU code from the trace backend risks infinite
recursion so we need to be limit that or add a counter to prevent
recursion.  Second, the qemu-timer.c code isn't build into qemu-tools,
whereas tracing should work across the whole codebase (usermode,
softmmu, tools, etc).  The ugly solution would be to add the Windows
timestamp code into simpletrace.c too.

While we're at it I'm going to add a 6th argument to the trace record
so we don't need to change the simple trace backend when someone needs
to trace 6 arguments ;).  Right now it support 0-5 arguments, but 6
seems like a reasonable limit.

Stefan



reply via email to

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