From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964865AbcALOiL (ORCPT ); Tue, 12 Jan 2016 09:38:11 -0500 Received: from mail.kernel.org ([198.145.29.136]:55207 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933622AbcALOiJ (ORCPT ); Tue, 12 Jan 2016 09:38:09 -0500 Date: Tue, 12 Jan 2016 11:38:05 -0300 From: Arnaldo Carvalho de Melo To: Peter Zijlstra Cc: Ingo Molnar , 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: <20160112143805.GX18367@kernel.org> References: <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> <20160112134012.GF6357@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160112134012.GF6357@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: X-Mailing-List: linux-kernel@vger.kernel.org Em Tue, Jan 12, 2016 at 02:40:12PM +0100, Peter Zijlstra escreveu: > 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. $ perf record -h build Usage: perf record [] [] or: perf record [] -- [] -B, --no-buildid do not collect buildids in perf.data -N, --no-buildid-cache do not update the buildid cache [acme@zoo linux]$ > 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. > 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. Right, for you -B is the only sane way (or doing that in ~/.perfconfig and disabling this for good). BTW, mtime would incur in postprocessing it all. - Arnaldo > > > 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.