linux-kernel - Re: [PATCH 3/3] perf record: mmap output file

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 15 Oct 2013 18:06:46 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	David Ahern <dsahern@...il.com>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	linux-kernel@...r.kernel.org,
	Frederic Weisbecker <fweisbec@...il.com>,
	Jiri Olsa <jolsa@...hat.com>,
	Namhyung Kim <namhyung@...nel.org>,
	Mike Galbraith <efault@....de>,
	Stephane Eranian <eranian@...gle.com>
Subject: Re: [PATCH 3/3] perf record: mmap output file


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

> On 10/15/13 9:27 AM, Ingo Molnar wrote:
> >
> >* Peter Zijlstra <peterz@...radead.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/