[Qemu-devel] Re: [PATCH 1/2] trace: Add simple tracing support

[Jan Kiszka]

Stefan Hajnoczi wrote:
> On Fri, May 21, 2010 at 12:13 PM, Jan Kiszka <address@hidden> wrote:
>> Stefan Hajnoczi wrote:
>>> Trace events should be defined in trace.h.  Events are written to
>>> /tmp/trace.log and can be formatted using trace.py.  Remember to add
>>> events to trace.py for pretty-printing.
>> When already writing to a file, why not reusing QEMU's logging
>> infrastructure ("log <foo>" / "-d foo")? Shouldn't make a huge
>> performance difference if the data is saved in clear-text.
> 
>> Also, having support for ftrace's user space markers would be a very
>> nice option (only an option as it's Linux-specific), see
>> http://lwn.net/Articles/366796.
> 
> Thanks for the links.
> 
> I think using the platform's tracing facility has many advantages.
> The main one being that we can focus on QEMU/KVM development rather
> than re-implementing tracing infrastructure :).

Indeed. :)

> 
> It may be possible to have SystemTap, DTrace, or nop static trace
> event code.  A platform with no tracing support can only use the nop
> backend, which results in a build without static trace events.
> Platforms with tracing support can build with the appropriate backend
> or nop.  The backend tracing facility is abstracted and most of QEMU
> doesn't need to know which one is being used.

That would be ideal.

> 
> I hadn't seen trace markers.  However, I suspect they aren't ideal for
> static trace events because logging an event requires a write system
> call.  They look useful for annotating kernel tracing information, but
> less for high frequency/low overhead userspace tracing.

You never know for sure until you tried :). There are surely lots of
scenarios where this overhead does not matter.

Moreover, I'm sure that something of LTTng's high-frequency/low-overhead
tracing capabilities will make it (in whatever form) into mainline
sooner or later. So we need that smart infrastructure to make use of it
once it's available (actually, LTTng is already available, just still
requires "some" kernel patching).

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux