lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 19 Jan 2010 13:51:45 +0000
From:	Jamie Iles <jamie.iles@...ochip.com>
To:	Arnaldo Carvalho de Melo <acme@...radead.org>
Cc:	Jamie Iles <jamie.iles@...ochip.com>,
	linux-perf-users@...r.kernel.org,
	Frédéric Weisbecker <fweisbec@...il.com>,
	Mike Galbraith <efault@....de>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Paul Mackerras <paulus@...ba.org>, Ingo Molnar <mingo@...e.hu>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
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@...opc7302:~# ./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@...opc7302:~# ./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@...opc7302:~# mv /boot/vmlinux /boot/vmlinux
root@...opc7302:~# mv /boot/vmlinux /boot/v
root@...opc7302:~# ./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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ