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

Ingo Molnar
2009-11-20T09:02:28Z

* 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