From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934542AbcALOe7 (ORCPT ); Tue, 12 Jan 2016 09:34:59 -0500 Received: from mail.kernel.org ([198.145.29.136]:54951 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933622AbcALOe6 (ORCPT ); Tue, 12 Jan 2016 09:34:58 -0500 Date: Tue, 12 Jan 2016 11:34:54 -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: <20160112143454.GV18367@kernel.org> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160112113521.GC6357@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 12:35:21PM +0100, Peter Zijlstra escreveu: > On Tue, Jan 12, 2016 at 11:39:43AM +0100, Ingo Molnar wrote: > > > Does the kernel even know about the buildid crap? AFAIK the binfmt stuff doesn't > > > know or care about things like that. Heck, we support binfmts that do not even > > > have a buildid. > > > > The kernel's exec() code does not care about the past, it will execute whatever is > > fit to execute right now. > > > > But perf tooling cares very much: it can lead to subtle bugs and bad data if we > > display a profile with the wrong DSO or binary. 'Bad' profiles resulting out of > > binary mismatch can be very convincing and can send developers down the wrong path > > for hours. I'd expect my tooling to not do that. > > 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. Humm, for most things today, i.e. ELF, most distros (all? maybe this is a gcc switch that is default on, haven't checked) come with such pre-computed cookie its just a way for efficiently passing it to the tooling via a new record. With that, no post processing, etc. But then someone would need to prototype this... [acme@zoo linux]$ 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]$ Have you ever played, when you noticed those overheads, with -N? Or just used the -B big hammer and moved on? - Arnaldo > > Path names alone (the thing that exec() cares about) are not unique enough to > > identify the binary that was profiled. So we need a content hash - hence the > > build-ID. > > > > Can you suggest a better solution than a build-time calculated content hash? > > Not really, but the current 'solution' is a massive pain. The result is > that perf-record needs to do a full scan of the recorded data after > completion and look for buildids across the system. > > On my system that pass takes longer than the actual workload (of > building a kernel). Furthermore, the resulting data is useless for me. > > > As for binary formats that suck and don't allow for a content hash: we do our > > best, but of course the risk of data mismatch is there. We could perhaps cache the > > binary inode's mtime field to at least produce a 'profile data is older than > > binary/DSO modification date!' warning. (Which check won't catch all cases, like > > cross-system profiling data matches.) > > So my problem with the kernel side thing is that I fear it will, again, > be a partial solution, and we'll still end up scanning the perf-record > output, ie. nothing better than we are now. > > Sure, maybe we can have binfmt_elf read the buildid and cache it > someplace, maybe we can even have the other binfmt thingies do something > similar (at small cost, we obviously cannot compute hashes over files at > exec() time, that would upset people). > > But what do we do for DSOs, does dlopen() ever end up in the binfmt > code? I would think not, I would fully expect the dynamic linker to just > mmap() the relevant bits and be done with it. > > And we cannot, at mmap() time, 'assume' the file is ELF and try prodding > into it to find a buildid or whatnot. > > And all for some weird corner case. > > ~ Peter, who thinks buildid stuff stinks.