From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753614Ab3KSQJp (ORCPT ); Tue, 19 Nov 2013 11:09:45 -0500 Received: from mail-pd0-f179.google.com ([209.85.192.179]:44298 "EHLO mail-pd0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753027Ab3KSQJn (ORCPT ); Tue, 19 Nov 2013 11:09:43 -0500 Message-ID: <528B8D44.1050601@gmail.com> Date: Tue, 19 Nov 2013 09:09:40 -0700 From: David Ahern User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Ingo Molnar , Peter Zijlstra CC: Namhyung Kim , Arnaldo Carvalho de Melo , linux-kernel@vger.kernel.org, jolsa@redhat.com, Frederic Weisbecker , Mike Galbraith , Stephane Eranian Subject: Re: [PATCH 4/5] perf record: mmap output file - v5 References: <528AB229.6030603@gmail.com> <87wqk5t9yd.fsf@sejong.aot.lge.com> <528ACA41.4030202@gmail.com> <87ob5ht962.fsf@sejong.aot.lge.com> <528ACDE7.3050107@gmail.com> <20131119065835.GB32367@gmail.com> <20131119114810.GK3866@twins.programming.kicks-ass.net> <20131119114959.GE3694@twins.programming.kicks-ass.net> <20131119131304.GC7263@gmail.com> <20131119134508.GN3866@twins.programming.kicks-ass.net> <20131119153142.GA10913@gmail.com> In-Reply-To: <20131119153142.GA10913@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/19/13, 8:31 AM, Ingo Molnar wrote: >> The only reason I reacted was because the changelog mentioned >> avoiding a feedback loop -- so I obviously had to point out that it >> didn't do such a thing, it only changed the details of the loop. > > So with MAP_POPULATE the 'feedback window' is moved entirely into the > kernel (to within a single syscall) and is also reduced significantly, > compared to a write() loop. As I understand it we have to use MAP_SHARED, not MAP_PRIVATE for files. So MAP_POPULATE does not work here. (And I tried to verify -- MAP_PRIVATE | MAP_POPULATE drops the feedback loop, but the file is 0's after the header). >> I'm fairly certain this particular problem is unavoidable, no matter >> what the mechanism used, you can always create feedback. > > Well, we could exclude the profiling task itself from profiling events > (just like ftrace and core bits of perf does it out of necessity), but > I intentionally wanted to avoid that, to make sure we are honest and > to make sure people don't tolerate profiling overhead that disturbs > other workloads. Samples generated by perf itself need to be observable -- e.g. process scheduling I want to see the time consumed by the data collector itself and there are times when 'perf trace -- perf ...' is useful. perf just needs options to do the right thing and stay out of its own way. Having a restriction that you can't do system wide collection of systems calls AND faults does not seem all that limiting. David