[lkml]   [2012]   [May]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Perf record format portability
    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 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 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 (~917 samples) ]

    The resulting 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/
    e731c64000993d1fd1b443e6d5d6972d149440e8 /lib64/
    [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

    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 (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.`


    Was the kernel trace events infrastructure designed with that in
    mind? I.e. cross analysis? I must be missing something here, still

    When doing cross arch event analisys I tested:



    PERF_TYPE_RAW = 4,

    - Arnaldo

     \ /
      Last update: 2012-05-16 17:21    [W:0.034 / U:49.168 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site