Re: [PATCH 0/6] MIPS: perf: Make perf work for 64-bit/Octeon counters.

[Deng-Cheng Zhu]

Hi, David


Today I did a quick test against your patch set on my MIPS32 Malta board.
After fixing a small compiling issue (see my comment for patch #5), I
successfully built the kernel based on my previous mainline-sync changes.
And when doing the test, I was using the an previously compiled 'perf'
tool, because the latest perf tool needs arch specific DWARF register
mapping definitions (and currently we have not yet submitted this patch).

And here's the test result:

# When this patch set is built in, the simple 'perf stat' command takes
very long time (182 seconds for the ls command). See following:

-sh-4.0# perf stat -e cycles -e instructions ls /
bin   dev  home  lost+found  opt   root  share  tmp    usr
boot  etc  lib   mnt         proc  sbin  sys    trans  var

 Performance counter stats for 'ls /':

         2825998290  cycles
         2148970283  instructions             #      0.760 IPC

      181.901999444  seconds time elapsed

# When this patch is NOT used, namely, only the mainline-sync changes are
built in, the time looks reasonable:

-sh-4.0# perf stat -e cycles -e instructions ls /
bin   dev  home  lost+found  opt   root  share  tmp    usr
boot  etc  lib   mnt         proc  sbin  sys    trans  var

 Performance counter stats for 'ls /':

            2051461  cycles
            1041512  instructions             #      0.508 IPC

        0.046426513  seconds time elapsed

I noticed that you changed quite a lot of original logics in MIPS
Perf-events, including the deletion of the 'msbs' member in the struct
cpu_hw_events. Honestly speaking, I have not yet taken a careful look into
the patch set to find out how you deal with the MIPS specific 0x80000000
counter overflow (certainly, the value is for MIPS32), instead of
0xffffffff. But maybe this code logic could be related to the test result.


Deng-Cheng


2011/1/7 David Daney <ddaney@xxxxxxxxxxxxxxxxxx>:
> The existing MIPS perf hardware counter support only handles 32-bit
> wide counters.  Some CPUs (like Octeon) have the 64-bit wide variety.
> This patch set allows perf to work on Octeon, and I hope not break
> existing systems.  I have not tested it on non-Octeon systems, so it
> would be good if someone could test that.
>
> Summary of the patches:
>
> 1) Fix faulty Octeon interrupt controller code.
>
> 2) Add some register definitions.
>
> 3,4) Clean up existing code.
>
> 5) 64-bit perf counter support.
>
> 6) Octeon perf event bindings.
>
> Patch 4/6 is the biggest and has the highest chance of having broken
> something.
>
> This patch set depends on a couple of others that have previously been
> sent to Ralf:
>
> http://patchwork.linux-mips.org/patch/1927/
> http://patchwork.linux-mips.org/patch/1850/
> http://patchwork.linux-mips.org/patch/1851/
> http://patchwork.linux-mips.org/patch/1852/
> http://patchwork.linux-mips.org/patch/1853/
> http://patchwork.linux-mips.org/patch/1854/
>
> David Daney (6):
>  MIPS: Octeon: Enable per-CPU IRQs on all CPUs.
>  MIPS: Add accessor macros for 64-bit performance counter registers.
>  MIPS: perf: Cleanup formatting in arch/mips/kernel/perf_event.c
>  MIPS: perf: Reorganize contents of perf support files.
>  MIPS: perf: Add support for 64-bit perf counters.
>  MIPS: perf: Add Octeon support for hardware perf.
>
>  arch/mips/Kconfig                    |    2 +-
>  arch/mips/cavium-octeon/octeon-irq.c |   30 +-
>  arch/mips/cavium-octeon/smp.c        |   10 +
>  arch/mips/include/asm/mipsregs.h     |    8 +
>  arch/mips/kernel/Makefile            |    5 +-
>  arch/mips/kernel/perf_event.c        |  521 +--------------
>  arch/mips/kernel/perf_event_mipsxx.c | 1265 +++++++++++++++++++++++++---------
>  7 files changed, 977 insertions(+), 864 deletions(-)
>
> Cc: Peter Zijlstra <a.p.zijlstra@xxxxxxxxx>
> Cc: Paul Mackerras <paulus@xxxxxxxxx>
> Cc: Ingo Molnar <mingo@xxxxxxx>
> Cc: Arnaldo Carvalho de Melo <acme@xxxxxxxxxx>
> Cc: Deng-Cheng Zhu <dengcheng.zhu@xxxxxxxxx>
> --
> 1.7.2.3
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/