Messages in this thread | | | Date | Mon, 21 Aug 2023 18:21:24 +0900 | From | Masami Hiramatsu (Google) <> | Subject | Re: [PATCH v2] tracing: Introduce pipe_cpumask to avoid race on trace_pipes |
| |
On Sun, 20 Aug 2023 22:33:01 -0400 Steven Rostedt <rostedt@goodmis.org> wrote:
> On Mon, 21 Aug 2023 11:19:54 +0900 > Masami Hiramatsu (Google) <mhiramat@kernel.org> wrote: > > > Ah, this caused a drop. errno can be EAGAIN even if rlen > 0. > > I've fixed this and that works. > > BTW, I think this virtio-trace would be better to move under > > tools/tracing because it is a tracing tool. > > I'm fine with that, as where it is, I'm very unfamiliar with this tool. > It is likely not taking advantage of all the tracing tooling we > have. I actually never even used it.
Actually I also used this after a long time. :P I think this is a kind of simplest splice support test tool.
What the tool does;
(guest side) per_cpu/cpu*/trace_pipe_raw | (splice) | anon-pipe | (splice) | virtio-serial chardev | = virtqueue === | named-fifo (host-side)
So that we can move the traced data (page) from the ring buffer to virtqueue. Then host tool can read the trace data without copying. (The host part needs a copy to read or write to file.) Obviously, this requires some integration work with other tracing tools, because this is just a "fastest trace-data dumper".
(I think Yoshihiro worked that integration, but it was not updated)
https://lkml.org/lkml/2013/9/12/788
Thank you,
-- Masami Hiramatsu (Google) <mhiramat@kernel.org>
| |