linux-kernel - Re: [RFC] perf record: missing buildid for callstack modules

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160112134012.GF6357@twins.programming.kicks-ass.net>
Date:	Tue, 12 Jan 2016 14:40:12 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Arnaldo Carvalho de Melo <acme@...nel.org>,
	Stephane Eranian <eranian@...gle.com>,
	Namhyung Kim <namhyung@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Jiri Olsa <jolsa@...nel.org>,
	Namhyung Kim <namhyung@...nel.org>,
	Adrian Hunter <adrian.hunter@...el.com>,
	"ak@...ux.intel.com" <ak@...ux.intel.com>
Subject: Re: [RFC] perf record: missing buildid for callstack modules

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.