Perf not resolving all symbols, showing 0x7ffffxxx

Perf not resolving all symbols, showing 0x7ffffxxx

[Martin Hicks]

Hi,

I've been trying to track down a performance regression that started
leading up to the v3.6 kernel, and while doing this I've been
gathering perf data on v3.6-rc and comparing it to v3.11 perf reports
of the same workload.

With v3.6-rc kernels I get all symbols resolved like this:

# Events: 39K cpu-clock-msecs
#
# Overhead      Command           Shared Object
            Symbol
# ........  ...........  ......................
........................................
#
     9.69%         nfsd  [kernel.kallsyms]       [k] csum_partial
     5.64%         nfsd  [kernel.kallsyms]       [k] __do_softirq
     3.12%         nfsd  [sunrpc]                [k] svc_create
     2.38%         nfsd  [kernel.kallsyms]       [k] __queue_work
     1.91%         nfsd  [gianfar_driver]        [k] gfar_poll
     1.73%         nfsd  [kernel.kallsyms]       [k] memset
     1.54%         nfsd  [nfsd]                  [k] nfsd_vfs_read.isra.16
     1.40%  ksoftirqd/0  [kernel.kallsyms]       [k] finish_task_switch.isra.54
     1.30%         nfsd  [kernel.kallsyms]       [k] get_page_from_freelist
     1.21%         nfsd  [gianfar_driver]        [k] gfar_start_xmit
     1.20%         nfsd  [sunrpc]                [k] svc_xprt_received


But when I perf on v3.11 kernels I see a lot of unresolved symbols:

# Events: 69K cpu-clock-msecs
#
# Overhead       Command          Shared Object
       Symbol
# ........  ............  .....................
...................................
#
    73.80%          nfsd  [unknown]              [k] 0x7ffff7fa
     7.57%          nfsd  [kernel.kallsyms]      [k] csum_partial
     4.59%   kworker/0:1  [unknown]              [k] 0x7ffff832
     3.76%   ksoftirqd/0  [unknown]              [k] 0x7ffff96e
     0.94%       kswapd0  [unknown]              [k] 0x7ffffcc2
     0.92%       swapper  [unknown]              [k] 0x7ffffa54
     0.62%          nfsd  [kernel.kallsyms]      [k] __udp4_lib_lookup
     0.49%          nfsd  [kernel.kallsyms]      [k] ip_append_page
     0.48%          nfsd  [kernel.kallsyms]      [k] __do_softirq
     0.36%      eventmon  [unknown]              [k] 0x7ffff9c4
     0.32%          nfsd  [kernel.kallsyms]      [k] __getnstimeofday


Any ideas?  Have I overlooked some necessary kernel config change?
Does perf need some binary that I may not have installed on this
embedded platform?

Freescale mpc8379 (e300c4)
Gcc-4.7.2 uClibC built with ct-ng 1.18.0
binutils 2.22

Thanks,
mh

-- 
Martin Hicks P.Eng.      |         mort@bork.org
Bork Consulting Inc.     |   +1 (613) 266-2296

Re: Perf not resolving all symbols, showing 0x7ffffxxx

[Martin Hicks]

I've tracked the start of the strange instruction pointers in 'perf
report' to a commit by Anton:

commit 75382aa72f06823db7312ad069c3bae2eb3f8548
Author: Anton Blanchard <anton@samba.org>
Date:   Tue Jun 26 01:01:36 2012 +0000

    powerpc/perf: Move code to select SIAR or pt_regs into perf_read_regs

I don't know enough about PPC to know what's going on, but reverting
the changes to perf_instruction_pointer() gets me reasonable 'perf
report' output with 3.11.

Thanks,
mh


On Thu, Oct 3, 2013 at 10:21 AM, Martin Hicks <mort@bork.org> wrote:
> Hi,
>
> I've been trying to track down a performance regression that started
> leading up to the v3.6 kernel, and while doing this I've been
> gathering perf data on v3.6-rc and comparing it to v3.11 perf reports
> of the same workload.
>
> With v3.6-rc kernels I get all symbols resolved like this:
>
> # Events: 39K cpu-clock-msecs
> #
> # Overhead      Command           Shared Object
>             Symbol
> # ........  ...........  ......................
> ........................................
> #
>      9.69%         nfsd  [kernel.kallsyms]       [k] csum_partial
>      5.64%         nfsd  [kernel.kallsyms]       [k] __do_softirq
>      3.12%         nfsd  [sunrpc]                [k] svc_create
>      2.38%         nfsd  [kernel.kallsyms]       [k] __queue_work
>      1.91%         nfsd  [gianfar_driver]        [k] gfar_poll
>      1.73%         nfsd  [kernel.kallsyms]       [k] memset
>      1.54%         nfsd  [nfsd]                  [k] nfsd_vfs_read.isra.16
>      1.40%  ksoftirqd/0  [kernel.kallsyms]       [k] finish_task_switch.isra.54
>      1.30%         nfsd  [kernel.kallsyms]       [k] get_page_from_freelist
>      1.21%         nfsd  [gianfar_driver]        [k] gfar_start_xmit
>      1.20%         nfsd  [sunrpc]                [k] svc_xprt_received
>
>
> But when I perf on v3.11 kernels I see a lot of unresolved symbols:
>
> # Events: 69K cpu-clock-msecs
> #
> # Overhead       Command          Shared Object
>        Symbol
> # ........  ............  .....................
> ...................................
> #
>     73.80%          nfsd  [unknown]              [k] 0x7ffff7fa
>      7.57%          nfsd  [kernel.kallsyms]      [k] csum_partial
>      4.59%   kworker/0:1  [unknown]              [k] 0x7ffff832
>      3.76%   ksoftirqd/0  [unknown]              [k] 0x7ffff96e
>      0.94%       kswapd0  [unknown]              [k] 0x7ffffcc2
>      0.92%       swapper  [unknown]              [k] 0x7ffffa54
>      0.62%          nfsd  [kernel.kallsyms]      [k] __udp4_lib_lookup
>      0.49%          nfsd  [kernel.kallsyms]      [k] ip_append_page
>      0.48%          nfsd  [kernel.kallsyms]      [k] __do_softirq
>      0.36%      eventmon  [unknown]              [k] 0x7ffff9c4
>      0.32%          nfsd  [kernel.kallsyms]      [k] __getnstimeofday
>
>
> Any ideas?  Have I overlooked some necessary kernel config change?
> Does perf need some binary that I may not have installed on this
> embedded platform?
>
> Freescale mpc8379 (e300c4)
> Gcc-4.7.2 uClibC built with ct-ng 1.18.0
> binutils 2.22
>
> Thanks,
> mh
>
> --
> Martin Hicks P.Eng.      |         mort@bork.org
> Bork Consulting Inc.     |   +1 (613) 266-2296



-- 
Martin Hicks P.Eng.      |         mort@bork.org
Bork Consulting Inc.     |   +1 (613) 266-2296

Re: Perf not resolving all symbols, showing 0x7ffffxxx

[Benjamin Herrenschmidt]

On Tue, 2013-10-15 at 09:59 -0400, Martin Hicks wrote:
> I've tracked the start of the strange instruction pointers in 'perf
> report' to a commit by Anton:
> 
> commit 75382aa72f06823db7312ad069c3bae2eb3f8548
> Author: Anton Blanchard <anton@samba.org>
> Date:   Tue Jun 26 01:01:36 2012 +0000
> 
>     powerpc/perf: Move code to select SIAR or pt_regs into perf_read_regs
> 
> I don't know enough about PPC to know what's going on, but reverting
> the changes to perf_instruction_pointer() gets me reasonable 'perf
> report' output with 3.11.

This is an e300 core right ? (603...). Do that have an SIAR at all
(Scott ?)


Cheers,
Ben.

> Thanks,
> mh
> 
> 
> On Thu, Oct 3, 2013 at 10:21 AM, Martin Hicks <mort@bork.org> wrote:
> > Hi,
> >
> > I've been trying to track down a performance regression that started
> > leading up to the v3.6 kernel, and while doing this I've been
> > gathering perf data on v3.6-rc and comparing it to v3.11 perf reports
> > of the same workload.
> >
> > With v3.6-rc kernels I get all symbols resolved like this:
> >
> > # Events: 39K cpu-clock-msecs
> > #
> > # Overhead      Command           Shared Object
> >             Symbol
> > # ........  ...........  ......................
> > ........................................
> > #
> >      9.69%         nfsd  [kernel.kallsyms]       [k] csum_partial
> >      5.64%         nfsd  [kernel.kallsyms]       [k] __do_softirq
> >      3.12%         nfsd  [sunrpc]                [k] svc_create
> >      2.38%         nfsd  [kernel.kallsyms]       [k] __queue_work
> >      1.91%         nfsd  [gianfar_driver]        [k] gfar_poll
> >      1.73%         nfsd  [kernel.kallsyms]       [k] memset
> >      1.54%         nfsd  [nfsd]                  [k] nfsd_vfs_read.isra.16
> >      1.40%  ksoftirqd/0  [kernel.kallsyms]       [k] finish_task_switch.isra.54
> >      1.30%         nfsd  [kernel.kallsyms]       [k] get_page_from_freelist
> >      1.21%         nfsd  [gianfar_driver]        [k] gfar_start_xmit
> >      1.20%         nfsd  [sunrpc]                [k] svc_xprt_received
> >
> >
> > But when I perf on v3.11 kernels I see a lot of unresolved symbols:
> >
> > # Events: 69K cpu-clock-msecs
> > #
> > # Overhead       Command          Shared Object
> >        Symbol
> > # ........  ............  .....................
> > ...................................
> > #
> >     73.80%          nfsd  [unknown]              [k] 0x7ffff7fa
> >      7.57%          nfsd  [kernel.kallsyms]      [k] csum_partial
> >      4.59%   kworker/0:1  [unknown]              [k] 0x7ffff832
> >      3.76%   ksoftirqd/0  [unknown]              [k] 0x7ffff96e
> >      0.94%       kswapd0  [unknown]              [k] 0x7ffffcc2
> >      0.92%       swapper  [unknown]              [k] 0x7ffffa54
> >      0.62%          nfsd  [kernel.kallsyms]      [k] __udp4_lib_lookup
> >      0.49%          nfsd  [kernel.kallsyms]      [k] ip_append_page
> >      0.48%          nfsd  [kernel.kallsyms]      [k] __do_softirq
> >      0.36%      eventmon  [unknown]              [k] 0x7ffff9c4
> >      0.32%          nfsd  [kernel.kallsyms]      [k] __getnstimeofday
> >
> >
> > Any ideas?  Have I overlooked some necessary kernel config change?
> > Does perf need some binary that I may not have installed on this
> > embedded platform?
> >
> > Freescale mpc8379 (e300c4)
> > Gcc-4.7.2 uClibC built with ct-ng 1.18.0
> > binutils 2.22
> >
> > Thanks,
> > mh
> >
> > --
> > Martin Hicks P.Eng.      |         mort@bork.org
> > Bork Consulting Inc.     |   +1 (613) 266-2296
> 
> 
> 

Re: Perf not resolving all symbols, showing 0x7ffffxxx

[Martin Hicks]

On Tue, Oct 15, 2013 at 11:30 AM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Tue, 2013-10-15 at 09:59 -0400, Martin Hicks wrote:
>> I've tracked the start of the strange instruction pointers in 'perf
>> report' to a commit by Anton:
>>
>> commit 75382aa72f06823db7312ad069c3bae2eb3f8548
>> Author: Anton Blanchard <anton@samba.org>
>> Date:   Tue Jun 26 01:01:36 2012 +0000
>>
>>     powerpc/perf: Move code to select SIAR or pt_regs into perf_read_regs
>>
>> I don't know enough about PPC to know what's going on, but reverting
>> the changes to perf_instruction_pointer() gets me reasonable 'perf
>> report' output with 3.11.
>
> This is an e300 core right ? (603...). Do that have an SIAR at all
> (Scott ?)

Yes, e300c3.

mh

-- 
Martin Hicks P.Eng.      |         mort@bork.org
Bork Consulting Inc.     |   +1 (613) 266-2296

Re: Perf not resolving all symbols, showing 0x7ffffxxx

[Benjamin Herrenschmidt]

On Tue, 2013-10-15 at 14:44 -0400, Martin Hicks wrote:
> On Tue, Oct 15, 2013 at 11:30 AM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> > On Tue, 2013-10-15 at 09:59 -0400, Martin Hicks wrote:
> >> I've tracked the start of the strange instruction pointers in 'perf
> >> report' to a commit by Anton:
> >>
> >> commit 75382aa72f06823db7312ad069c3bae2eb3f8548
> >> Author: Anton Blanchard <anton@samba.org>
> >> Date:   Tue Jun 26 01:01:36 2012 +0000
> >>
> >>     powerpc/perf: Move code to select SIAR or pt_regs into perf_read_regs
> >>
> >> I don't know enough about PPC to know what's going on, but reverting
> >> the changes to perf_instruction_pointer() gets me reasonable 'perf
> >> report' output with 3.11.
> >
> > This is an e300 core right ? (603...). Do that have an SIAR at all
> > (Scott ?)
> 
> Yes, e300c3.

Ok so I have a hard time figuring out how that patch can make a
difference since for all I can see, there is no perf backend upstream
for e300 at all :-(

I must certainly be missing something ... Scott, can you have a look ?

Cheers,
Ben.

Re: Perf not resolving all symbols, showing 0x7ffffxxx

[Scott Wood]

On Tue, 2013-10-15 at 14:53 -0500, Benjamin Herrenschmidt wrote:
> On Tue, 2013-10-15 at 14:44 -0400, Martin Hicks wrote:
> > On Tue, Oct 15, 2013 at 11:30 AM, Benjamin Herrenschmidt
> > <benh@kernel.crashing.org> wrote:
> > > On Tue, 2013-10-15 at 09:59 -0400, Martin Hicks wrote:
> > >> I've tracked the start of the strange instruction pointers in 'perf
> > >> report' to a commit by Anton:
> > >>
> > >> commit 75382aa72f06823db7312ad069c3bae2eb3f8548
> > >> Author: Anton Blanchard <anton@samba.org>
> > >> Date:   Tue Jun 26 01:01:36 2012 +0000
> > >>
> > >>     powerpc/perf: Move code to select SIAR or pt_regs into perf_read_regs
> > >>
> > >> I don't know enough about PPC to know what's going on, but reverting
> > >> the changes to perf_instruction_pointer() gets me reasonable 'perf
> > >> report' output with 3.11.
> > >
> > > This is an e300 core right ? (603...). Do that have an SIAR at all
> > > (Scott ?)
> > 
> > Yes, e300c3.
> 
> Ok so I have a hard time figuring out how that patch can make a
> difference since for all I can see, there is no perf backend upstream
> for e300 at all :-(
> 
> I must certainly be missing something ... Scott, can you have a look ?

e300c3 has a core-fsl-emb style performance monitor (though Linux
doesn't support it yet).  If a bug was bisected to a change in
core-book3s.c, then it's probably a coincidence due to moving code
around.

-Scott

Re: Perf not resolving all symbols, showing 0x7ffffxxx

[Benjamin Herrenschmidt]

On Tue, 2013-10-15 at 15:22 -0500, Scott Wood wrote:
> On Tue, 2013-10-15 at 14:53 -0500, Benjamin Herrenschmidt wrote:
> > On Tue, 2013-10-15 at 14:44 -0400, Martin Hicks wrote:
> > > On Tue, Oct 15, 2013 at 11:30 AM, Benjamin Herrenschmidt
> > > <benh@kernel.crashing.org> wrote:
> > > > On Tue, 2013-10-15 at 09:59 -0400, Martin Hicks wrote:
> > > >> I've tracked the start of the strange instruction pointers in 'perf
> > > >> report' to a commit by Anton:
> > > >>
> > > >> commit 75382aa72f06823db7312ad069c3bae2eb3f8548
> > > >> Author: Anton Blanchard <anton@samba.org>
> > > >> Date:   Tue Jun 26 01:01:36 2012 +0000
> > > >>
> > > >>     powerpc/perf: Move code to select SIAR or pt_regs into perf_read_regs
> > > >>
> > > >> I don't know enough about PPC to know what's going on, but reverting
> > > >> the changes to perf_instruction_pointer() gets me reasonable 'perf
> > > >> report' output with 3.11.
> > > >
> > > > This is an e300 core right ? (603...). Do that have an SIAR at all
> > > > (Scott ?)
> > > 
> > > Yes, e300c3.
> > 
> > Ok so I have a hard time figuring out how that patch can make a
> > difference since for all I can see, there is no perf backend upstream
> > for e300 at all :-(
> > 
> > I must certainly be missing something ... Scott, can you have a look ?
> 
> e300c3 has a core-fsl-emb style performance monitor (though Linux
> doesn't support it yet).  If a bug was bisected to a change in
> core-book3s.c, then it's probably a coincidence due to moving code
> around.

Mort, can you see if just that change is enough to cause the problem ?

------------------- arch/powerpc/include/asm/perf_event.h --------------------
index 5c16b89..0bb2372 100644
@@ -26,8 +26,13 @@
 #include <asm/ptrace.h>
 #include <asm/reg.h>
 
+/*
+ * Overload regs->result to specify whether we should use the MSR (result
+ * is zero) or the SIAR (result is non zero).
+ */
 #define perf_arch_fetch_caller_regs(regs, __ip)			\
 	do {							\
+		(regs)->result = 0;				\
 		(regs)->nip = __ip;				\
 		(regs)->gpr[1] = *(unsigned long *)__get_SP();	\
 		asm volatile("mfmsr %0" : "=r" ((regs)->msr));	\

Ben.

Re: Perf not resolving all symbols, showing 0x7ffffxxx

[Martin Hicks]

Actually, I was wrong, the mpc8379 is an e300c4.

So it seems clear to me that we compile in the book3s code because
this is an 83xx CPU part.  I also see that Kconfig knows that I have
an core-fsl-emb but we don't actually compile the PMU backend for it
because there's no support for anything but e500.

mort@chinook:~/src/s4v2-glibc/linux-mpc$ grep PERF .config
CONFIG_FSL_EMB_PERFMON=y
CONFIG_PPC_PERF_CTRS=y
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_EVENTS=y
# CONFIG_DEBUG_PERF_USE_VMALLOC is not set
mort@chinook:~/src/s4v2-glibc/linux-mpc$ grep BOOK3S .config
CONFIG_PPC_BOOK3S_32=y
CONFIG_PPC_BOOK3S=y

more below...

On Tue, Oct 15, 2013 at 4:39 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Tue, 2013-10-15 at 15:22 -0500, Scott Wood wrote:
>> On Tue, 2013-10-15 at 14:53 -0500, Benjamin Herrenschmidt wrote:
>> > On Tue, 2013-10-15 at 14:44 -0400, Martin Hicks wrote:
>> > > >
>> > > > This is an e300 core right ? (603...). Do that have an SIAR at all
>> > > > (Scott ?)
>> > >
>> > > Yes, e300c3.
>> >
>> > Ok so I have a hard time figuring out how that patch can make a
>> > difference since for all I can see, there is no perf backend upstream
>> > for e300 at all :-(
>> >
>> > I must certainly be missing something ... Scott, can you have a look ?
>>
>> e300c3 has a core-fsl-emb style performance monitor (though Linux
>> doesn't support it yet).  If a bug was bisected to a change in
>> core-book3s.c, then it's probably a coincidence due to moving code
>> around.

CONFIG_PPC_PERF_CTRS seems to give the mpc8379 some kind of basic
performance measuring.  Is this through dummy_perf() in
arch/powerpc/kernel/pmc.c?

>
> Mort, can you see if just that change is enough to cause the problem ?

It is not.  The patch that does get IPs working again in my 3.11 tree
is this one:

diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index eeae308..9a3f572 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -122,10 +122,6 @@ void power_pmu_flush_branch_stack(void) {}
 static inline void power_pmu_bhrb_read(struct cpu_hw_events *cpuhw) {}
 #endif /* CONFIG_PPC32 */

-static bool regs_use_siar(struct pt_regs *regs)
-{
-       return !!regs->result;
-}

 /*
  * Things that are specific to 64-bit implementations.
@@ -1802,14 +1798,13 @@ unsigned long perf_misc_flags(struct pt_regs *regs)
  */
 unsigned long perf_instruction_pointer(struct pt_regs *regs)
 {
-       bool use_siar = regs_use_siar(regs);
-
-       if (use_siar && siar_valid(regs))
-               return mfspr(SPRN_SIAR) + perf_ip_adjust(regs);
-       else if (use_siar)
-               return 0;               // no valid instruction pointer
-       else
+       unsigned long mmcra = regs->dsisr;
+       if (TRAP(regs) != 0xf00)
+               return regs->nip;
+       if ((ppmu->flags & PPMU_NO_CONT_SAMPLING) &&
+           !(mmcra & MMCRA_SAMPLE_ENABLE))
                return regs->nip;
+       return mfspr(SPRN_SIAR) + perf_ip_adjust(regs);
 }

 static bool pmc_overflow_power7(unsigned long val)


mh

-- 
Martin Hicks P.Eng.      |         mort@bork.org
Bork Consulting Inc.     |   +1 (613) 266-2296

Re: Perf not resolving all symbols, showing 0x7ffffxxx

[Benjamin Herrenschmidt]

On Wed, 2013-10-16 at 11:05 -0400, Martin Hicks wrote:
> Actually, I was wrong, the mpc8379 is an e300c4.
> 
> So it seems clear to me that we compile in the book3s code because
> this is an 83xx CPU part.  I also see that Kconfig knows that I have
> an core-fsl-emb but we don't actually compile the PMU backend for it
> because there's no support for anything but e500.
> 
> mort@chinook:~/src/s4v2-glibc/linux-mpc$ grep PERF .config
> CONFIG_FSL_EMB_PERFMON=y
> CONFIG_PPC_PERF_CTRS=y
> CONFIG_HAVE_PERF_EVENTS=y
> CONFIG_PERF_EVENTS=y
> # CONFIG_DEBUG_PERF_USE_VMALLOC is not set
> mort@chinook:~/src/s4v2-glibc/linux-mpc$ grep BOOK3S .config
> CONFIG_PPC_BOOK3S_32=y
> CONFIG_PPC_BOOK3S=y
> 
> more below...
> 
> On Tue, Oct 15, 2013 at 4:39 PM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> > On Tue, 2013-10-15 at 15:22 -0500, Scott Wood wrote:
> >> On Tue, 2013-10-15 at 14:53 -0500, Benjamin Herrenschmidt wrote:
> >> > On Tue, 2013-10-15 at 14:44 -0400, Martin Hicks wrote:
> >> > > >
> >> > > > This is an e300 core right ? (603...). Do that have an SIAR at all
> >> > > > (Scott ?)
> >> > >
> >> > > Yes, e300c3.
> >> >
> >> > Ok so I have a hard time figuring out how that patch can make a
> >> > difference since for all I can see, there is no perf backend upstream
> >> > for e300 at all :-(
> >> >
> >> > I must certainly be missing something ... Scott, can you have a look ?
> >>
> >> e300c3 has a core-fsl-emb style performance monitor (though Linux
> >> doesn't support it yet).  If a bug was bisected to a change in
> >> core-book3s.c, then it's probably a coincidence due to moving code
> >> around.
> 
> CONFIG_PPC_PERF_CTRS seems to give the mpc8379 some kind of basic
> performance measuring.  Is this through dummy_perf() in
> arch/powerpc/kernel/pmc.c?
> 
> >
> > Mort, can you see if just that change is enough to cause the problem ?
> 
> It is not.  The patch that does get IPs working again in my 3.11 tree
> is this one:
> 
> diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
> index eeae308..9a3f572 100644
> --- a/arch/powerpc/perf/core-book3s.c
> +++ b/arch/powerpc/perf/core-book3s.c
> @@ -122,10 +122,6 @@ void power_pmu_flush_branch_stack(void) {}
>  static inline void power_pmu_bhrb_read(struct cpu_hw_events *cpuhw) {}
>  #endif /* CONFIG_PPC32 */
> 
> -static bool regs_use_siar(struct pt_regs *regs)
> -{
> -       return !!regs->result;
> -}

Can you try instead just chaning regs_use_siar to return false always ?
Do that help ?

Cheers,
Ben.

>  /*
>   * Things that are specific to 64-bit implementations.
> @@ -1802,14 +1798,13 @@ unsigned long perf_misc_flags(struct pt_regs *regs)
>   */
>  unsigned long perf_instruction_pointer(struct pt_regs *regs)
>  {
> -       bool use_siar = regs_use_siar(regs);
> -
> -       if (use_siar && siar_valid(regs))
> -               return mfspr(SPRN_SIAR) + perf_ip_adjust(regs);
> -       else if (use_siar)
> -               return 0;               // no valid instruction pointer
> -       else
> +       unsigned long mmcra = regs->dsisr;
> +       if (TRAP(regs) != 0xf00)
> +               return regs->nip;
> +       if ((ppmu->flags & PPMU_NO_CONT_SAMPLING) &&
> +           !(mmcra & MMCRA_SAMPLE_ENABLE))
>                 return regs->nip;
> +       return mfspr(SPRN_SIAR) + perf_ip_adjust(regs);
>  }
> 
>  static bool pmc_overflow_power7(unsigned long val)
> 
> 
> mh
> 

Re: Perf not resolving all symbols, showing 0x7ffffxxx

[Martin Hicks]

On Wed, Oct 16, 2013 at 2:42 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Wed, 2013-10-16 at 11:05 -0400, Martin Hicks wrote:
>> Actually, I was wrong, the mpc8379 is an e300c4.
>>
>> So it seems clear to me that we compile in the book3s code because
>> this is an 83xx CPU part.  I also see that Kconfig knows that I have
>> an core-fsl-emb but we don't actually compile the PMU backend for it
>> because there's no support for anything but e500.
>>
>> mort@chinook:~/src/s4v2-glibc/linux-mpc$ grep PERF .config
>> CONFIG_FSL_EMB_PERFMON=y
>> CONFIG_PPC_PERF_CTRS=y
>> CONFIG_HAVE_PERF_EVENTS=y
>> CONFIG_PERF_EVENTS=y
>> # CONFIG_DEBUG_PERF_USE_VMALLOC is not set
>> mort@chinook:~/src/s4v2-glibc/linux-mpc$ grep BOOK3S .config
>> CONFIG_PPC_BOOK3S_32=y
>> CONFIG_PPC_BOOK3S=y
>>
>> more below...
>>
>> On Tue, Oct 15, 2013 at 4:39 PM, Benjamin Herrenschmidt
>> <benh@kernel.crashing.org> wrote:
>> > On Tue, 2013-10-15 at 15:22 -0500, Scott Wood wrote:
>> >> On Tue, 2013-10-15 at 14:53 -0500, Benjamin Herrenschmidt wrote:
>> >> > On Tue, 2013-10-15 at 14:44 -0400, Martin Hicks wrote:
>> >> > > >
>> >> > > > This is an e300 core right ? (603...). Do that have an SIAR at all
>> >> > > > (Scott ?)
>> >> > >
>> >> > > Yes, e300c3.
>> >> >
>> >> > Ok so I have a hard time figuring out how that patch can make a
>> >> > difference since for all I can see, there is no perf backend upstream
>> >> > for e300 at all :-(
>> >> >
>> >> > I must certainly be missing something ... Scott, can you have a look ?
>> >>
>> >> e300c3 has a core-fsl-emb style performance monitor (though Linux
>> >> doesn't support it yet).  If a bug was bisected to a change in
>> >> core-book3s.c, then it's probably a coincidence due to moving code
>> >> around.
>>
>> CONFIG_PPC_PERF_CTRS seems to give the mpc8379 some kind of basic
>> performance measuring.  Is this through dummy_perf() in
>> arch/powerpc/kernel/pmc.c?
>>
>> >
>> > Mort, can you see if just that change is enough to cause the problem ?
>>
>> It is not.  The patch that does get IPs working again in my 3.11 tree
>> is this one:
>>
>> diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
>> index eeae308..9a3f572 100644
>> --- a/arch/powerpc/perf/core-book3s.c
>> +++ b/arch/powerpc/perf/core-book3s.c
>> @@ -122,10 +122,6 @@ void power_pmu_flush_branch_stack(void) {}
>>  static inline void power_pmu_bhrb_read(struct cpu_hw_events *cpuhw) {}
>>  #endif /* CONFIG_PPC32 */
>>
>> -static bool regs_use_siar(struct pt_regs *regs)
>> -{
>> -       return !!regs->result;
>> -}
>
> Can you try instead just chaning regs_use_siar to return false always ?
> Do that help ?
>

That does fix the problem.  v3.11 with the following:

diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index eeae308..e91cf67 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -124,7 +124,7 @@ static inline void power_pmu_bhrb_read(struct
cpu_hw_events *cpuhw) {}

 static bool regs_use_siar(struct pt_regs *regs)
 {
-       return !!regs->result;
+       return 0; //!!regs->result;
 }

 /*


mh

-- 
Martin Hicks P.Eng.      |         mort@bork.org
Bork Consulting Inc.     |   +1 (613) 266-2296

Re: Perf not resolving all symbols, showing 0x7ffffxxx

[Benjamin Herrenschmidt]

On Wed, 2013-10-16 at 17:16 -0400, Martin Hicks wrote:

> That does fix the problem.  v3.11 with the following:
> 
> diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
> index eeae308..e91cf67 100644
> --- a/arch/powerpc/perf/core-book3s.c
> +++ b/arch/powerpc/perf/core-book3s.c
> @@ -124,7 +124,7 @@ static inline void power_pmu_bhrb_read(struct
> cpu_hw_events *cpuhw) {}
> 
>  static bool regs_use_siar(struct pt_regs *regs)
>  {
> -       return !!regs->result;
> +       return 0; //!!regs->result;
>  }

Ok, we probably need that function to do that on machines with no
backend :-) Either that or properly clear regs->result always.


I've had a quick look through perf and I admit I'm not sure of all the
ways perf ends up populating "regs" here and how many holes there is
in that scheme :-)

Anton? How do you know for sure regs is always be cooked by your stuff
(for regs->result) ?

Ben.