Re: [RFC][PATCH 1/2] perf: Add 'perf kmem' tool

[Ingo Molnar <mingo@elte.hu>]

* 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