Messages in this thread | | | Date | Fri, 3 Jul 2009 10:53:38 +0200 | From | Ingo Molnar <> | Subject | Re: [patch 0/4] perf_counter tools: support annotation of live kernel modules |
| |
* Frederic Weisbecker <fweisbec@gmail.com> wrote:
> On Fri, Jul 03, 2009 at 09:17:39AM +0200, Mike Galbraith wrote: > > On Thu, 2009-07-02 at 14:10 +0200, Peter Zijlstra wrote: > > > On Thu, 2009-07-02 at 09:17 +0200, Mike Galbraith wrote: > > > > > > > I've been pondering a perf archive tool > > > > that would package everything that's needed to do analysis on a > > > > different box. One big problem though, is that while you can easily > > > > package vmlinux and modules, what about all the userland binaries? A > > > > large perf.data and/or debug info binaries can easily make transport > > > > impractical enough. > > > > > > I would simply extend the current file header with another section in > > > which we do a structured storage of the data structures we currently > > > build in perf-report. That is, the dso and symbol bits. > > > > > > If we then run perf-report on a file containing such a section we read > > > that data instead of trying to locate them the regular way. > > > > That's a good idea. > > > > If uname doesn't match stored record time uname, you're not live, so > > tools require an exportable perf.data. If you're not live and not on > > the same host, annotate requires binaries appended via an export tool > > with --sym-filter -k -u -% whatever capability. > > > > -Mike > > > Also that would make easier the implementation of a perf compare > thing. A perf compare may have several uses, including: > > (1) comparing different workloads with a same executable. > (2) comparing different executable versions for a same workload > (3) (1) + (2) ? > > For the (2), having self contained record files as operands would > let comparisons based on symbols, pretty useful when you have to > compare two different vmlinux (or whatever binary executable).
very good points.
Ingo
| |