Re: Tracing block devices (was: Re: [Qemu-devel] Static tracepoint control via trace-event)

["Daniel P. Berrange" <berrange@redhat.com>]

On Tue, Oct 19, 2010 at 03:29:51PM +0100, Richard W.M. Jones wrote:
> On Tue, Oct 19, 2010 at 03:59:36PM +0200, Jan Kiszka wrote:
> > Once we have "-trace events=...", defining the list of active
> > tracepoints before starting qemu will be trivial (e.g. via a config
> > file). Of course, this requires that all tracepoints are built-in...
> 
> Sorry that I've not been following this very closely, but does this
> sort of thing allow tracing reads and writes to block devices?  Am I
> right in thinking that if a tracepoint existed in the right place, one
> could get a log file from that which could be post-processed in
> another tool?
> 
> cf:
> http://rwmj.wordpress.com/2010/10/05/visualizing-reads-writes-and-alignment/#content

While having a static tracepoint in the right place would be best, it
is not strictly neccessary with a tool like DTrace/SystemTAP. With the
qemu debuginfo available, those tools can dynamically insert a probe
into any QEMU function at any point in the code. So you could easily
replace your QEMU patch from that blog post with a simple trace script
and get the same info dynamically. The benefit of static markers is 
that they can provide standard named probe point + args,  which are 
stable long term, even as the code is re-factored/renamed/moved, etc.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|