[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <500E161F.5020207@hitachi.com>
Date: Tue, 24 Jul 2012 12:27:27 +0900
From: Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
To: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@...achi.com>
Cc: linux-kernel@...r.kernel.org, Amit Shah <amit.shah@...hat.com>,
Anthony Liguori <anthony@...emonkey.ws>,
Arnd Bergmann <arnd@...db.de>, Borislav Petkov <bp@...64.org>,
"Franch Ch. Eigler" <fche@...hat.com>,
Frederic Weisbecker <fweisbec@...il.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Herbert Xu <herbert@...dor.apana.org.au>,
Ingo Molnar <mingo@...hat.com>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Steven Rostedt <rostedt@...dmis.org>,
virtualization@...ts.linux-foundation.org, qemu-devel@...gnu.org,
yrl.pp-manager.tt@...achi.com
Subject: Re: [RFC PATCH 0/6] virtio-trace: Support virtio-trace
(2012/07/24 11:36), Yoshihiro YUNOMAE wrote:
> Therefore, we propose a new system "virtio-trace", which uses enhanced
> virtio-serial and existing ring-buffer of ftrace, for collecting guest kernel
> tracing data. In this system, there are 5 main components:
> (1) Ring-buffer of ftrace in a guest
> - When trace agent reads ring-buffer, a page is removed from ring-buffer.
> (2) Trace agent in the guest
> - Splice the page of ring-buffer to read_pipe using splice() without
> memory copying. Then, the page is spliced from write_pipe to virtio
> without memory copying.
> (3) Virtio-console driver in the guest
> - Pass the page to virtio-ring
> (4) Virtio-serial bus in QEMU
> - Copy the page to kernel pipe
> (5) Reader in the host
> - Read guest tracing data via FIFO(named pipe)
So, this is our answer for the argued points in previous thread.
This virtio-serial and ftrace enhancements doesn't introduce new
"ringbuffer" in the kernel, and just use virtio's ringbuffer.
Also, using splice gives us a great advantage in the performance
because of copy-less trace-data transfer.
Actually, one copy should occur in the host (to write it into the pipe),
because removing physical pages of the guest is hard to track and may
involve a TLB flush per page, even if it is done in background.
Thank you,
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@...achi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists