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 S1755095AbcASP1x (ORCPT <rfc822;w@1wt.eu>);
	Tue, 19 Jan 2016 10:27:53 -0500
Received: from casper.infradead.org ([85.118.1.10]:60235 "EHLO
	casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1754846AbcASP1r (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 19 Jan 2016 10:27:47 -0500
Date: Tue, 19 Jan 2016 16:27:42 +0100
From: Peter Zijlstra <peterz@infradead.org>
To: Namhyung Kim <namhyung@kernel.org>
Cc: Ingo Molnar <mingo@kernel.org>, Arnaldo Carvalho de Melo <acme@kernel.org>,
        Stephane Eranian <eranian@google.com>,
        LKML <linux-kernel@vger.kernel.org>, Jiri Olsa <jolsa@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: <20160119152742.GI6356@twins.programming.kicks-ass.net>
References: <CABPqkBRqkwj02jZHoQxpxOH7FjYTjAa_mLdZWvSWfv1-oqsuPQ@mail.gmail.com>
 <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>
 <20160112142357.GS18367@kernel.org>
 <20160113095738.GA9092@gmail.com>
 <20160119145640.GF1324@danjae.kornet>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160119145640.GF1324@danjae.kornet>
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 19, 2016 at 11:56:40PM +0900, Namhyung Kim wrote:

> > But but ... why is #2 a problem with mtime? If we have an out of date record in 
> > the perf.data, then the perf.data is uninteresting in 99% of the usecases! It's 
> > out of date, most likely because the binary the developer is working on got 
> > rebuilt, or the system got upgraded - in both cases the developer does not care 
> > about the old records anymore...
> 
> We have 'perf diff' command which compares old and new performance
> results of a same program.  People can use it to see how much improved
> in the new version than the baseline.  In this case, the old binary
> should be found from the old perf.data.

Just means they'll have to use perf-archive or whatnot before that
works. Making the regular perf-record dead slow just so that a few more
complex workloads work doesn't make sense.