Adding Jiri and Steven to the CC list.
Em Wed, May 16, 2012 at 02:50:31PM +0400, Dmitry Antipov escreveu:
> On 05/15/2012 07:51 PM, Arnaldo Carvalho de Melo wrote:
> >Em Tue, May 15, 2012 at 07:27:39PM +0400, Dmitry Antipov escreveu:
> >>are there any thoughts on how much of the perf.data is portable and how
> >>much it should be?
> >>I'm interesting in recording scheduler activity on one machine and then
> >>replaying on
> >>another. As I can see, replaying x86 perf.data on ARM doesn't work. At
> >>least, should it
> >>work with a small subset of recorded events (for example,
> >>sched:sched_switch,
> >>sched:sched_process_exit, sched:sched_process_fork, sched:sched_wakeup
> >>and sched:sched_migrate_task) on the same architecture?
> >
> >Endianness issues? ARM EB? There are some patches by Jiri Olsa that may
> >help you if that is the case.
>
> Thanks, will look at.
>
> >It should be portable, are you using 'perf archive' too?
>
> It doesn't work with cryptic messages like:
>
> tar: .build-id/17/d6ca02b2c31df54bf62a4142c47e3c99a9eedf: Cannot stat: No
> such file or directory
It is a shell script, basically, after yum collect your events with
something like:
[acme@sandy ~]$ perf record -F 10000 sleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.021 MB perf.data (~917 samples) ]
The resulting perf.data file will have samples taken on these DSOs,
with those respective hashes identifying each one:
[acme@sandy ~]$ perf buildid-list
4390a3d2dc84c37a8923ba4c910d6766abc42cbf [kernel.kallsyms]
ceb82e745b0ab8bb7ea28c068327be1fb068c923 /lib64/ld-2.12.so
e731c64000993d1fd1b443e6d5d6972d149440e8 /lib64/libc-2.12.so
[acme@sandy ~]$
In your case we can see that it is looking for build id
17d6ca02b2c31df54bf62a4142c47e3c99a9eedf on the build id cache.
Probably you either are running 'perf archive' on a different machine
than the one where you ran 'perf record' or using a different user on
the same machine, or, unlikely, perhaps you removed ~/.debug/ after
'record'.
The 'perf archive' tool was done quickly just as a proof of concept,
admitedly it needs to be improved to help diagnosing these problems.
> creating empty archive.
>
> >What exactly is the error experienced?
>
> Now I'm facing the simple problem with event IDs, which may be different from
> machine to
> machine. For example, /sys/kernel/debug/tracing/events/sched/sched_switch/id
> is 55 on my ARM
> board and 279 on my PC host, so 'perf report' displays all event names like
> "unknown:unknown",
> even with --kallsyms=XXX where XXX is 'cat /proc/kallsyms > XXX' from PC host.
With build-ids and 'perf archive' you shouldn't need specifying
kallsyms, it has a build-id and will be collected (record + archive) an
then transfered and expanded on the analysis machine (scp + tar xvf).
The tracing part even stashes a copy of kallsyms in perf.data (not
needed, but there for historical reasons). The problem is in translating
the perf_event_attr.config to the same name and format as in the machine
where you collected the events.`
Steve,
Was the kernel trace events infrastructure designed with that in
mind? I.e. cross analysis? I must be missing something here, still
ENOCOFFEE :-\
When doing cross arch event analisys I tested:
PERF_TYPE_HARDWARE = 0,
PERF_TYPE_SOFTWARE = 1,
PERF_TYPE_HW_CACHE = 3,
Not:
PERF_TYPE_TRACEPOINT = 2,
PERF_TYPE_RAW = 4,
PERF_TYPE_BREAKPOINT = 5,
- Arnaldo
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
