Re: off-box analysis of perf.data file

[Arnaldo Carvalho de Melo <acme@ghostprotocols.net>]

Em Thu, Nov 18, 2010 at 02:54:27PM -0700, David S. Ahern escreveu:
> Hmmm.... From a user perspective maintaining build-id databases for
> short-use builds is more complex than using a --rootfs argument. i.e.,
> add rootfs to symbol_conf with a default value of "", add a --rootfs
> argument to analysis commands to allow a user to specify a path, and
> within dso__load prepend the paths within rootfs. This appears to be
> similar to what has been done for builtin-kvm and analyzing guest
> data.  Furthermore, this allows a wide range of options - loop
> mounting KVM disk images, NFS trees, bootable USB keys, initrds, etc.
> Anything with an OS tree can be analyzed from anywhere without the
> need to populate a local data store.
 
> Similar argument for kallsyms point to a file rather than pointing to
> /proc/kallsyms -- which again parallels what has been done for builtin-kvm.

Yeah, I think it is worth having it for maximum flexibility, can you try
to implement it and post the patch for discussion?

> "perf" in the above meant all the commands that eventually call
> dso__load. In my F14 - F13 test case (data collected on a Fedora 14
> system and analyzed on a Fedora 13 system), 'strace -e trace=open perf
> report ...' shows perf opening a lot of files on the F13 system - even
> though the ~/.debug tree was populated using perf-archive.

What 'perf buildid-list' shows on this specific perf.data file? Perhaps
it is not finding the build-ids somehow and so fallbacks to looking at
the system binaries, checking if they have the same build-id, if
build-ids are present on the perf.data file header.

There is a bit of historical baggage here, in the pre-build-id days the
tools would look just at the pathnames, assuming the binaries hadn't
changed, etc.

- Arnaldo