Messages in this thread | | | Date | Tue, 19 Jan 2010 13:51:45 +0000 | From | Jamie Iles <> | Subject | Re: Analysing an ARM perf.data file on a x86-64 workstation |
| |
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
| |