(2012/07/24 19:02), Stefan Hajnoczi wrote:
On Tue, Jul 24, 2012 at 3:36 AM, Yoshihiro YUNOMAE
<address@hidden> 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,