From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964883AbcALNkT (ORCPT ); Tue, 12 Jan 2016 08:40:19 -0500 Received: from bombadil.infradead.org ([198.137.202.9]:55321 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752822AbcALNkR (ORCPT ); Tue, 12 Jan 2016 08:40:17 -0500 Date: Tue, 12 Jan 2016 14:40:12 +0100 From: Peter Zijlstra To: Ingo Molnar Cc: Arnaldo Carvalho de Melo , Stephane Eranian , Namhyung Kim , LKML , Jiri Olsa , Namhyung Kim , Adrian Hunter , "ak@linux.intel.com" Subject: Re: [RFC] perf record: missing buildid for callstack modules Message-ID: <20160112134012.GF6357@twins.programming.kicks-ass.net> References: <20160107215945.GA19314@kernel.org> <80F05A66-6943-499A-B402-96249953CD15@gmail.com> <20160107234746.GB19314@kernel.org> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160112121805.GA32199@gmail.com> User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 12, 2016 at 01:18:05PM +0100, Ingo Molnar wrote: > > Well, it really is rather a rare case, replacing binaries you're > > profiling. Sure, if it happens (by accident or otherwise) it can be a > > pain, but the cost of fixing this 'problem' is huge. > > But isn't this the common case for developers, who rebuild their binaries all the > time, while profiling them? Looking at the wrong profile without having an > indication that it's wrong is a problem. I tend to: 1: edit code compile code (perf) run code inspect profile goto 1 which does not have this problem at all. Only if you want to inspect 'old' profiles does this problem occur. > > On my system that pass takes longer than the actual workload (of building a > > kernel). Furthermore, the resulting data is useless for me. > > Hm, that's a powerful performance argument. Why is it so slow? I'd assume that by > default we only need to save the build-ID itself per object - which is like 20 > bytes? There is no buildid in the recorded data, I think it looks at every MMAP record, finds the associated file, extracts the buildid and copies crap into .debug directory. Also, just parsing the gigabytes of data that comes out of perf-record takes significant time, let alone poking around the filesystem and copying files around. Furthermore, I have 40 CPUs generating data, while only a single one is doing all this post-processing. # rm -rf ~/.debug/ # make O=defconfig-build/ clean; perf record make O=defconfig-build/ -j80 -s # ls -lah perf.data -rw------- 1 root root 2.7G Jan 12 14:18 perf.data # du -sh ~/.debug/ 240M /root/.debug/ That's a lot of pointless work. > > And all for some weird corner case. > > So could we perhaps just switch the whole thing over to be mtime based: mtime is > pretty indicative of whether a binary is the right one or not. > > And mtime could be checked at perf report time, not at perf record time: we'd only > have to check whether the mtime of the object we read at perf report time is newer > than the mtime of the perf.data (the creation of the profile). > > This does not solve rare corner cases like cross-system profiling, but I think the > common case should not be burdened with the overhead of a rare case. That might work, we have easy access to the mtime data for any file.