perf: ARM: Record the user-mode PC in the call chain.
Subsystems (3)
PATCH 1/1 perf: ARM: Record the user-mode PC in the call chain.
With this change, we no longer lose the innermost entry in the user-mode part of the call chain. See also the x86 port, which includes the ip.
It's possible to partially work around this problem by post-processing the data to use the PERF_SAMPLE_IP value, but this works only if the CPU wasn't in the kernel when the sample was taken.
--- arch/arm/kernel/perf_event.c | 1 + 1 file changed, 1 insertion(+)
arch/arm/kernel/perf_event.c +1 -0
@@ -569,6 +569,7 @@ perf_callchain_user(struct perf_callchain_entry *entry, struct pt_regs *regs)return ; } +perf_callchain_store (entry, regs->ARM_pc); tail = (struct frame_tail __user *)regs->ARM_fp -1 ; while ((entry->nr < PERF_MAX_STACK_DEPTH) &&
Signature · 1 line
1.7.10.4
Quoted 6 lines · Jed Davis
With this change, we no longer lose the innermost entry in the user-mode part of the call chain. See also the x86 port, which includes the ip.
It's possible to partially work around this problem by post-processing the data to use the
PERF_SAMPLE_IPvalue, but this works only if the CPU wasn't in the kernel when the sample was taken.
Thanks. I guess we need something similar for arm64 too. Could you cook a similar patch please?
Will
Quoted 10 lines · Will Deacon
Quoted 6 lines · Jed Davis
With this change, we no longer lose the innermost entry in the user-mode part of the call chain. See also the x86 port, which includes the ip.
It's possible to partially work around this problem by post-processing the data to use the
PERF_SAMPLE_IPvalue, but this works only if the CPU wasn't in the kernel when the sample was taken.Thanks. I guess we need something similar for arm64 too. Could you cook a similar patch please?
Done (and tested, on the ARM V8 Foundation Model).
It looked as if the powerpc and sparc ports might have similar issues, but I haven't checked on them yet.
--Jed
Quoted 5 lines · Jed Davis
Quoted 4 lines · Will Deacon
Quoted 3 lines · Jed Davis
With this change, we no longer lose the innermost entry in the user-mode part of the call chain. See also the x86 port, which includes the ip.
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
It's possible to partially work around this problem by post-processing the data to use the
PERF_SAMPLE_IPvalue, but this works only if the CPU wasn't in the kernel when the sample was taken.Thanks. I guess we need something similar for arm64 too. Could you cook a similar patch please?
Done (and tested, on the ARM V8 Foundation Model).
Wow, I didn't expect you to test it. Thanks!
Quoted 2 lines
It looked as if the powerpc and sparc ports might have similar issues, but I haven't checked on them yet.
I can extract some hardware from the pile in the corner of my flat if you want a hand with testing.
Will
Will Deacon [will.deacon at arm.com] wrote:
| On Thu, Jun 20, 2013 at 04:17:06AM +0100, Jed Davis wrote: | > On Tue, Jun 18, 2013 at 02:13:19PM +0100, Will Deacon wrote: | > > On Fri, Jun 14, 2013 at 12:21:11AM +0100, Jed Davis wrote: | > > > With this change, we no longer lose the innermost entry in the user-mode | > > > part of the call chain. See also the x86 port, which includes the ip. | > > > | > > > It's possible to partially work around this problem by post-processing | > > > the data to use the PERF_SAMPLE_IP value, but this works only if the CPU | > > > wasn't in the kernel when the sample was taken. | > > | > > Thanks. I guess we need something similar for arm64 too. Could you cook a | > > similar patch please? | > | > Done (and tested, on the ARM V8 Foundation Model). | | Wow, I didn't expect you to test it. Thanks! | | > It looked as if the powerpc and sparc ports might have similar issues, | > but I haven't checked on them yet. | | I can extract some hardware from the pile in the corner of my flat if you | want a hand with testing.
Interesting. Powerpc already saves the next_ip for the first entry:
arch/powerpc/perf/callchain.c:
perf_callchain_user_64():
...
next_ip = perf_instruction_pointer(regs);
lr = regs->link;
sp = regs->gpr[1];
perf_callchain_store(entry, next_ip);
for (;;) {Do you have a test case/output that I can run on Power ?
We actually have the opposite problem where we see duplication in callchains like this. We considered not saving the "link register" but that seems to break for a "leaf-node" functions.
13.65% sprintft libc-2.12.so [.] __random
|
--- __random
|
|--62.82%-- __random
| |
| |--97.31%-- rand
| | do_my_sprintf
| | main
| | generic_start_main
| | __libc_start_main
| | 0x0
| |
| --2.69%-- do_my_sprintf
| main
| generic_start_main
| __libc_start_main
| 0x0
|
--37.18%-- rand
|
|--93.30%-- rand
| do_my_sprintf
| main
| generic_start_main
| __libc_start_main
| 0x0
|
--6.70%-- do_my_sprintf
main
generic_start_main
__libc_start_main
0x0