Re: Analysing an ARM perf.data file on a x86-64 workstation

[Jamie Iles <jamie.iles@picochip.com>]

Hi Arnaldo,

On Tue, Jan 19, 2010 at 11:09:58AM -0200, Arnaldo Carvalho de Melo wrote:
> CCing linux-perf-users, this may be interesting when investigating
> similar problems for other arches.
> 
> Thanks James, got the vmlinux file and and already found and fixed two
> bugs, patches sent CCed to you.
> 
> Ok, now how does it look like?
Well, with both patches applied, I still don't see any kernel symbols in perf
top (even the raw addresses) or resolved names in report if I specify a
vmlinux or if one gets autodetected.

For example, when keeping the CPU busy with 'dd if=/dev/zero of=/dev/null', If
I record with 'perf record -af -- sleep 1' then:

root@picopc7302:~# ./perf record -af -- sleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.071 MB perf.data (~3092 samples) ]
root@picopc7302:~# ./perf report --vmlinux=/tmp/vmlinux -v | head -10
no symbols found in /bin/busybox, maybe install a debug package?
# Samples: 435596970
#
# Overhead          Command           Shared Object  Symbol
# ........  ...............  ......................  ......
#   
    81.14%               dd                c0020ac8  0x00000000c0020ac8 ! [k] 0x000000c0020ac8
     9.26%             perf                c0071bfc  0x00000000c0071bfc ! [k] 0x000000c0071bfc
     3.53%               dd  /bin/busybox            0x000000000001d6f4 K [.] 0x0000000001d6f4
     1.55%            sleep                c006c3a0  0x00000000c006c3a0 ! [k] 0x000000c006c3a0
     1.38%               dd  /lib/libc-2.8.so        0x00000000000b4a2c d [.] __GI___libc_read
root@picopc7302:~# mv /boot/vmlinux /boot/vmlinux
root@picopc7302:~# mv /boot/vmlinux /boot/v
root@picopc7302:~# ./perf report -v | head -10
Looking at the vmlinux_path (5 entries long)
no symbols found in /bin/busybox, maybe install a debug package?
# Samples: 435596970
#
# Overhead          Command           Shared Object  Symbol
# ........  ...............  ......................  ......
#   
    32.57%               dd  [kernel.kallsyms]       0x00000000c02aaef0 k [k] _raw_spin_unlock_irqrestore
    12.30%               dd  [kernel.kallsyms]       0x00000000c006b5c4 k [k] lock_acquire
     6.23%               dd  [kernel.kallsyms]       0x00000000c006c220 k [k] lock_release
     5.38%               dd  [kernel.kallsyms]       0x00000000c006b9f0 k [k] lock_acquired
     5.04%               dd  [kernel.kallsyms]       0x00000000c0020ac8 k [k] vector_swi
> 
[snip]
> 
> But what about the other addresses for [k]ernel space perf hits such as
> 0xc0020ac4, 0xc0068f48, etc?
> 
> 0xc0020ac4 is around here:
> 
>    385: 00000000     0 FILE    LOCAL  DEFAULT  ABS process.c
> <SNIP>
>    411: c0020aa0    40 FUNC    LOCAL  DEFAULT    3 default_idle
>    412: c0020ac8     0 NOTYPE  LOCAL  DEFAULT    3 $a
> 
> so its well possible that this is really a very idle machine, right?
Yes, the run I sent you was pretty much just idling away.

Jamie