(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@sandy 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 majord...@vger.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...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
