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 S1762757AbcALPes (ORCPT <rfc822;w@1wt.eu>);
	Tue, 12 Jan 2016 10:34:48 -0500
Received: from bombadil.infradead.org ([198.137.202.9]:40829 "EHLO
	bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752776AbcALPeq (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 12 Jan 2016 10:34:46 -0500
Date: Tue, 12 Jan 2016 16:34:40 +0100
From: Peter Zijlstra <peterz@infradead.org>
To: Arnaldo Carvalho de Melo <acme@kernel.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: <20160112153440.GJ6357@twins.programming.kicks-ass.net>
References: <80F05A66-6943-499A-B402-96249953CD15@gmail.com>
 <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160112143805.GX18367@kernel.org>
User-Agent: Mutt/1.5.21 (2012-12-30)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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.

It doesn't get you right data, but knowing your data is broken allows
you to manually do things 'right'.