(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 debugfs.) 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 change. Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu.pt@xxxxxxxxxxx _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
