Re: Re: [RFC PATCH 0/6] virtio-trace: Support virtio-trace

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

(2012/07/24 19:02), Stefan Hajnoczi wrote:
> On Tue, Jul 24, 2012 at 3:36 AM, Yoshihiro YUNOMAE
> <yoshihiro.yunomae.ez@xxxxxxxxxxx> wrote:
>> The performance of each method is compared as follows:
>>  [1] Native
>>      - only recording trace data to ring-buffer on a guest
>>  [2] Virtio-trace
>>      - running a trace agent on a guest
>>      - a reader on a host opens FIFO using cat command
>>  [3] IVRing
>>      - A SystemTap script in a guest records trace data to IVRing.
>>        -- probe points are same as ftrace.
>>  [4] Virtio-serial(normal)
>>      - A reader(using cat) on a guest output trace data to a host using
>>        standard output via virtio-serial.
> The first time I read this I thought you are adding a new virtio-trace
> device.  But it looks like this series really add splice support to
> virtio-console and that yields a big performance improvement when
> sending trace_pipe_raw.

Yes, sorry for the confusion. Actually this is an enhancement of
virtio-serial. I'm working with Yoshihiro on this feature.

> Guest ftrace is useful and I like this.  Have you thought about
> controlling ftrace from the host?  Perhaps a command could be added to
> the QEMU guest agent which basically invokes trace-cmd/perf.

As you can see, guest trace-agent can be controlled via a
control channel. In our scenario, host tools can control that
instead of guest one.

We are considering that exporting the tracing part of guest's
debugfs to host via another virtio-serial channel by using
9pfs, so that the host tools can refer that.

(In this scenario, guest trace-agent will also provide 9pfs server.
Since it means that the agent can handle writing a special file,
trace-agent can be controlled via the special file on exported

Of course, this also requires modifying trace-cmd/perf to accept
some options like guest-debugfs mount point, guest's serial
channel pipe (or unix socket?), etc. However, it will be a small

Thank you,

Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
Virtualization mailing list

[KVM Development]     [Libvirt Development]     [Libvirt Users]     [CentOS Virtualization]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Photo]     [Yosemite]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]     [Find Someone Nice]     [Video 4 Linux]     [Linux Resources]
Add to Google Powered by Linux