Re: [RFC PATCH -v2 0/4] Persistent events

[Steven Rostedt]

On Fri, 2012-08-17 at 09:38 +0200, Borislav Petkov wrote:
> On Thu, Aug 16, 2012 at 06:00:18PM -0400, Steven Rostedt wrote:
> > Do these need to be mmapped, or are they copied into another location
> > (disk or network)? I had code to allow the ftrace ring buffers to be
> > mmapped, but stopped that work a while ago.
> 
> Well, my angle here is that since those are persistent, i.e. always-on
> events, they should be as low overhead as possible. So mmaping the
> buffer is probably that since it doesn't involve any data shuffling to
> and fro...

Understood.

> 
> > > > I'm currently working on having perf read ftrace data, so in the near
> > > > future, I plan on having some RFC patches to have perf reading from
> > > > this buffer anyway.
> > > 
> > > Are you saying the ftrace buffer would be mmappable too now?
> > 
> > No, the ftrace buffer was optimized for the splice command.
> 
> Ah, the splice thing moving data between two fds.

Yep.

> 
> > I would have perf do what trace-cmd does. That is, write directly into
> > a file as it reads it, without ever needing the info to come into
> > userspace.
> 
> Is that a real file?

It's anything that needs a file descriptor. But yeah.

> 
> Because what I was doing in the RAS daemon is mmap the buffer, read out
> the logged events in userspace and work on them.

OK, so you're not storing the data, your just using it to manipulate it.

If it wasn't for sparc, we could have done this with the ftrace buffers,
but sparc has some crazy requirement that physical pages can only be
mapped at certain locations, and you can't just take a bunch of random
pages and map them at the same location.

> 
> Having them go to a file which I need to open in userspace adds one more
> step and I don't know how that would pan out in a critical situation of
> you getting a machine check where every insn counts. And besides, in a
> MCE situation you cannot be sure that the events would actually go to
> file... So my current impression is that reading them direct from memory
> is the fastest we can do. But this is only me and I have been wrong in
> the past. Lotsa times :).
> 
> > I wasn't planning on replacing perf buffers, I was just planning on
> > giving perf a tracing boost.
> 
> Cool.
> 
> > Another alternative, which would be a bit slower, would be to copy the
> > pages, either into userspace (as a read) or into a location to mmap the
> > buffers.
> 
> Yeah, copying is not a good idea, IMHO, due to the said above.

I agree.

> 
> > I could also continue the work on allowing ftrace buffers to be
> > mmapped. But if the best thing to do is just use the perf buffers,
> > then we could just stick with that.
> 
> The easiest for now, I'd say, since it is already there.

Yeah, I agree with this too. As the perf buffer is better for
manipulating of data and not storing it.


-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/