On Sat, 21 Mar 2020 19:13:51 +0000 David Laight <David.Laight@xxxxxxxxxx> wrote: > From: Steven Rostedt > > Sent: 19 March 2020 23:22 > ... > > > > 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. > > Does this mean the you will no longer be able to look at a snapshot > of the trace by running 'less trace' (and typically going to the end > to get info for all cpus). If there's a use case for this, it will be trivial to add an option to bring back the old behavior. If you want that, I can do that, and even add a config that makes it the default. > > A lot of the time trace is being written far too fast for it to make > any sense to try to read it continuously. > > Also, if BPF start using ftrace, no one will be able to use it for > 'normal debugging' on such systems. I believe its used for debugging bpf, not for normal tracing. BPF only uses this when it has their trace_printk() using it. Which gives that nasty "THIS IS A DEBUG KERNEL" message ;-) Thus, I don't think you need to worry about bpf having this in production. -- Steve
