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 S1762117AbcALPsU (ORCPT <rfc822;w@1wt.eu>);
	Tue, 12 Jan 2016 10:48:20 -0500
Received: from mail.kernel.org ([198.145.29.136]:33214 "EHLO mail.kernel.org"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S934072AbcALPsQ (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 12 Jan 2016 10:48:16 -0500
Date: Tue, 12 Jan 2016 12:48:12 -0300
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>, Stephane Eranian <eranian@google.com>,
        Namhyung Kim <namhyung@gmail.com>, LKML <linux-kernel@vger.kernel.org>,
        Jiri Olsa <jolsa@kernel.org>, Namhyung Kim <namhyung@kernel.org>,
        Adrian Hunter <adrian.hunter@intel.com>,
        "ak@linux.intel.com" <ak@linux.intel.com>
Subject: Re: [RFC] perf record: missing buildid for callstack modules
Message-ID: <20160112154812.GH18367@kernel.org>
References: <20160107234746.GB19314@kernel.org>
 <CABPqkBRQ+4UAkumX8BLkWQmrqVTKOnOjQWpDij2jiDZTmrnOrQ@mail.gmail.com>
 <20160108181942.GB20576@kernel.org>
 <20160111173036.GA6344@twins.programming.kicks-ass.net>
 <20160112103943.GA6310@gmail.com>
 <20160112113521.GC6357@twins.programming.kicks-ass.net>
 <20160112121805.GA32199@gmail.com>
 <20160112134012.GF6357@twins.programming.kicks-ass.net>
 <20160112143805.GX18367@kernel.org>
 <20160112153440.GJ6357@twins.programming.kicks-ass.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160112153440.GJ6357@twins.programming.kicks-ass.net>
X-Url: http://acmel.wordpress.com
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Em Tue, Jan 12, 2016 at 04:34:40PM +0100, Peter Zijlstra escreveu:
> On Tue, Jan 12, 2016 at 11:38:05AM -0300, Arnaldo Carvalho de Melo wrote:
> > > Also, just parsing the gigabytes of data that comes out of perf-record
> > > takes significant time, let alone poking around the filesystem and
> > 
> > Right, that is what we would elliminate with stashing the content-based
> > cookie into a PERF_RECORD_MMAP3 record.
> 
> Again, how would you go about getting that cookie for a DSO? The whole
> kernel isn't involved with dlopen(), all it sees is a mmap(PROT_EXEC).
> 
> > BTW, mtime would incur in postprocessing it all.
> 
> mtime can still warn you if things are non-matching at report time
> without this post-processing, and thereby solves the problem of staring
> at broken/wrong data.

How will we collect the mtime for the DSOs in PERF_RECORD_MMAP records
if we don't look at those records? What mtime are you talking about?
 
> It doesn't get you right data, but knowing your data is broken allows
> you to manually do things 'right'.