lkml.org 
[lkml]   [2013]   [Oct]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 3/3] perf record: mmap output file

* David Ahern <dsahern@gmail.com> wrote:

> On 10/15/13 9:27 AM, Ingo Molnar wrote:
> >
> >* Peter Zijlstra <peterz@infradead.org> wrote:
> >
> >>On Tue, Oct 15, 2013 at 11:32:45AM -0300, Arnaldo Carvalho de Melo wrote:
> >>
> >>>Jiri and PeterZ probaby will have comments here... ;-) :-)
> >>
> >>The only complication with splice is the vmalloc support; other than
> >>that it should be fairly straight fwd.
> >
> >In the initial version we could skip splice support for vmalloc
> >ring-buffer, to keep things simple.
> >
> > Wanna send a patch for people to try? Looks like there's real interest
> > in speeding up perf record as much as possible!
>
> My second -- and more important -- concern about splice has been dropped
> from this path:
>
> "splice is also a system call and it would have to be invoked for each
> mmap each trip through the loop -- just like write() does today -- so it
> does not solve the feedback loop problem. "
>
> Am I missing something on how splice works?

splice() is very fast and should be able to process a lot of pages in one
go, so the feedback loop should be pretty weak. mmap() triggers kernel
code as well, every time we run out of the 64 MB window we got to remap
it, right?

But that's all just theory - I think non-temporal stores have a pretty
good chance of being a very good solution as well.

Thanks,

Ingo


\
 
 \ /
  Last update: 2013-10-15 18:21    [W:0.086 / U:0.404 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site