From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Steven Rostedt <rostedt@goodmis.org>, bpf <bpf@vger.kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Peter Zijlstra <peterz@infradead.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
Peter Wu <peter@lekensteyn.nl>, Jonathan Corbet <corbet@lwn.net>,
Tom Zanussi <zanussi@kernel.org>
Subject: Re: [RFC][PATCH 00/11] ring-buffer/tracing: Remove disabling of ring buffer while reading trace file
Date: Wed, 18 Mar 2020 19:27:28 -1000 [thread overview]
Message-ID: <CAADnVQ+hpVnsfKUNNeJWs8X0ogvsR8uNKrEzz5CK2XRdqn+80A@mail.gmail.com> (raw)
In-Reply-To: <20200317213222.421100128@goodmis.org>
On Tue, Mar 17, 2020 at 11:34 AM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> When the ring buffer was first written for ftrace, there was two
> human readable files to read it. One was a standard "producer/consumer"
> file (trace_pipe), which would consume data from the ring buffer as
> it read it, and the other was a "static iterator" that would not
> consume the events, such that the file could be read multiple times
> and return the same output each time.
>
> The "static iterator" was never meant to be read while there was an
> active writer to the ring buffer. If writing was enabled, then it
> would disable the writer when the trace file was opened.
>
> There has been some complaints about this by the BPF folks, that did
> not realize this little bit of information and it was requested that
> the "trace" file does not stop the writing to the ring buffer.
>
> This patch series attempts to satisfy that request, by creating a
> temporary buffer in each of the per cpu iterators to place the
> read event into, such that it can be passed to users without worrying
> about a writer to corrupt the event while it was being written out.
> It also uses the fact that the ring buffer is broken up into pages,
> where each page has its own timestamp that gets updated when a
> writer crosses over to it. By copying it to the temp buffer, and
> doing a "before and after" test of the time stamp with memory barriers,
> can allow the events to be saved.
Awesome. Thank you so much for working on it.
Looks like it addresses all the issues bpf folks reported.
cc-ing bpf list for visibility.
parent reply other threads:[~2020-03-19 5:27 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <20200317213222.421100128@goodmis.org>]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAADnVQ+hpVnsfKUNNeJWs8X0ogvsR8uNKrEzz5CK2XRdqn+80A@mail.gmail.com \
--to=alexei.starovoitov@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=bpf@vger.kernel.org \
--cc=corbet@lwn.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=mingo@kernel.org \
--cc=peter@lekensteyn.nl \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=zanussi@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).