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: <20160112143805.GX18367@kernel.org>
Date:	Tue, 12 Jan 2016 11:38:05 -0300
From:	Arnaldo Carvalho de Melo <acme@...nel.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Ingo Molnar <mingo@...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

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 [<options>] [<command>]
    or: perf record [<options>] -- <command> [<options>]

    -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.