[PATCH] perf: ARM: Record the user-mode PC in the call chain.

[PATCH] perf: ARM: Record the user-mode PC in the call chain.

[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_IP value, but this works only if the CPU
wasn't in the kernel when the sample was taken.

Signed-off-by: Jed Davis <jld@mozilla.com>
---
 arch/arm/kernel/perf_event.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index 8c3094d..d9f5cd4 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -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) &&
-- 
1.7.10.4

Re: [PATCH] perf: ARM: Record the user-mode PC in the call chain.

[Will Deacon]

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?

Will

Re: [PATCH] perf: ARM: Record the user-mode PC in the call chain.

[Jed Davis]

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

It looked as if the powerpc and sparc ports might have similar issues,
but I haven't checked on them yet.

--Jed

Re: [PATCH] perf: ARM: Record the user-mode PC in the call chain.

[Will Deacon]

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.

Will

Re: [PATCH] perf: ARM: Record the user-mode PC in the call chain.

[Sukadev Bhattiprolu]

Will Deacon [will.deacon@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