From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1759527Ab3JOQGv (ORCPT <rfc822;w@1wt.eu>);
	Tue, 15 Oct 2013 12:06:51 -0400
Received: from mail-ee0-f43.google.com ([74.125.83.43]:56903 "EHLO
	mail-ee0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1758971Ab3JOQGt (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 15 Oct 2013 12:06:49 -0400
Date: Tue, 15 Oct 2013 18:06:46 +0200
From: Ingo Molnar <mingo@kernel.org>
To: David Ahern <dsahern@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
        Arnaldo Carvalho de Melo <acme@ghostprotocols.net>,
        linux-kernel@vger.kernel.org, Frederic Weisbecker <fweisbec@gmail.com>,
        Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org>,
        Mike Galbraith <efault@gmx.de>, Stephane Eranian <eranian@google.com>
Subject: Re: [PATCH 3/3] perf record: mmap output file
Message-ID: <20131015160646.GC16003@gmail.com>
References: <1381289214-24885-1-git-send-email-dsahern@gmail.com>
 <1381289214-24885-4-git-send-email-dsahern@gmail.com>
 <20131009055957.GA7664@gmail.com>
 <525D4B5F.4090005@gmail.com>
 <20131015143245.GB9828@ghostprotocols.net>
 <20131015143819.GM10651@twins.programming.kicks-ass.net>
 <20131015152747.GA15979@gmail.com>
 <525D5FA1.7060404@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <525D5FA1.7060404@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


* 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