Messages in this thread | | | Date | Fri, 20 Nov 2009 10:01:34 +0100 | From | Ingo Molnar <> | Subject | Re: [RFC][PATCH 1/2] perf: Add 'perf kmem' tool |
| |
* Pekka Enberg <penberg@cs.helsinki.fi> wrote:
> Ingo Molnar kirjoitti: > >Regarding patch 2 - can we set some definitive benchmark threshold > >for that? I.e. a list of must-have features in 'perf kmem' before > >we can do it? 100% information and analysis equivalency with > >kmemtrace-user tool? > > I'd be interested to hear Eduard's comment on that. > > That said, I'll try to find some time to test "perf kmem" and > provide feedback on that. I can ACK the patch when I'm happy with > the output. :-) > > I'm mostly interested in two scenarios: (1) getting a nice report on > worst fragmented call-sites (perf kmem needs symbol lookup) and (2) > doing "perf kmem record" on machine A (think embedded here) and then > "perf kmem report" on machine B. I haven't tried kmemtrace-user for > a while but it did support both of them quite nicely at some point.
The perf.data can be copied over and to get off-side kernel symbol resolution you can specify the kernel vmlinux via -k/--vmlinux to perf report, then perf will look up the symbols from that vmlinux.
Cross word-size data files should work fine - cross-endian probably needs a few fixes.
Plus off-site user-space symbols need more work, right now we dont embedd them in the perf.data. It would need a symbol lookup + embedd-it pass in perf record (perhaps available as a separate 'perf archive' command as well), and some smarts on the reporting side to make use of them. (Probably a copy of all relevant DSOs is what works best - that enables off-site annotate as well.)
But ... even without that, perf is really fast and is supposed to build fine even in minimal (embedded) environments, so you can run it on the embedded board too. That's useful to get live inspection features like 'perf top', 'perf stat' and 'perf probe' anyway.
Ingo
| |