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]
Message-ID: <509A75F3.3060409@hitachi.com>
Date:	Wed, 07 Nov 2012 23:53:39 +0900
From:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
To:	Arnaldo Carvalho de Melo <acme@...stprotocols.net>
Cc:	Stephane Eranian <eranian@...gle.com>,
	linux-kernel@...r.kernel.org, Andi Kleen <andi@...stfloor.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Namhyung Kim <namhyung@...il.com>,
	Jiri Olsa <jolsa@...hat.com>, Ingo Molnar <mingo@...nel.org>,
	"yrl.pp-manager.tt@...achi.com" <yrl.pp-manager.tt@...achi.com>
Subject: Re: Re: [PATCH v2 00/16] perf: add memory access sampling support

(2012/11/07 5:52), Arnaldo Carvalho de Melo wrote:
> Em Mon, Nov 05, 2012 at 02:50:47PM +0100, Stephane Eranian escreveu:
>> Or if one is interested in the data view:
>> $ perf mem -t load rep --sort=symbol_daddr,cost
>> # Samples: 19K of event 'cpu/mem-loads/pp'
>> # Total cost : 1013994
>> # Sort order : symbol_daddr,cost
>> #
>> # Overhead      Samples             Data Symbol     Cost
>> # ........  ...........  ......................  .......
>> #
>>      0.10%            1  [.] 0x00007f67dffe8038      986
>>      0.09%            1  [.] 0x00007f67df91a750      890
>>      0.08%            1  [.] 0x00007f67e288fba8      826
>>
> 
>> CAVEAT: Note that the data addresses are not resolved correctly currently due to a
>> problem in perf data symbol resolution code which I have not been able to
>> uncover so far.
> 
> Stephane,
> 
> 	Those data addresses mostly are on the stack, we need reverse
> resolution using DWARF location expressions to figure out what is the
> name of a variable that is on a particular address, etc.
> 
> 	Masami, have you played with this already? I mean:

No, but it looks interesting. I'll try :)

> 
> [root@...dy acme]# perf mem -t load rep --stdio --sort=symbol,symbol_daddr,cost
> # Samples: 30  of event 'cpu/mem-loads/pp'
> # Total cost : 640
> # Sort order : symbol,symbol_daddr,cost
> #
> # Overhead      Samples                  Symbol             Data Symbol     Cost
> # ........  ...........  ......................  ......................  .......
> #
>     55.00%            1  [k] lookup_fast         [k] 0xffff8803b7521bd4      352
>      5.47%            1  [k] cache_alloc_refill  [k] 0xffff880407705024       35
>      3.44%            1  [k] cache_alloc_refill  [k] 0xffff88041d8527d8       22
>      3.28%            1  [k] run_timer_softirq   [k] 0xffff88041e2c3e90       21
>      2.50%            1  [k] __list_add          [k] 0xffff8803b7521d68       16
>      2.19%            1  [.] __strcoll_l         [.] 0x00007fffa8d44080       14
>      1.88%            1  [.] __strcoll_l         [.] 0x00007fffa8d44104       12
> 
> If we go to the annotation browser to see where is that lookup_fast hitting we get:
> 
> 100.00 │       mov    -0x34(%rbp),%eax
> 
> How to map 0xffff8803b7521bd4 to a stack variable, struct members and all?

If perf stores %rbp value, we can do forward searching from local variables
in this scope block. In some cases, the memory is dereferenced by another
pointer. In that case, it is hard to do that (perhaps, we need to disassemble
it and reverse execution). But in most case of the memory address on a stack,
it will work, I think.

Thank you,

> 
> Humm, for userspace we have PERF_SAMPLE_REGS_USER for the dwarf unwinder we
> need for userspace, but what about reverse mapping of kernel variables? Jiri?
> 
> - Arnaldo
> --
> 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/
> 


-- 
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@...achi.com


--
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