All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Daney <ddaney@caviumnetworks.com>
To: Deng-Cheng Zhu <dengcheng.zhu@gmail.com>
Cc: linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: Re: [PATCH 0/6] MIPS: perf: Make perf work for 64-bit/Octeon counters.
Date: Fri, 21 Jan 2011 16:17:53 -0800	[thread overview]
Message-ID: <4D3A2231.1040802@caviumnetworks.com> (raw)
In-Reply-To: <AANLkTimZKz_Epg8DOvwkWWcS0viUa2V2TygUS80osEwh@mail.gmail.com>

On 01/20/2011 01:59 AM, Deng-Cheng Zhu wrote:
> 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.
>
>

Can you test the new version of my patches I just posted?  I think I may 
have fixed this issue, but I cannot actually test 32-bit counters.

I think I was initializing the counters to the wrong value in the 32-bit 
case.  This would have caused an almost unending stream of counter 
overflow interrupts, thus slowing things down

David Daney

      parent reply	other threads:[~2011-01-22  0:18 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-07  2:35 [PATCH 0/6] MIPS: perf: Make perf work for 64-bit/Octeon counters David Daney
2011-01-07  2:35 ` [PATCH 1/6] MIPS: Octeon: Enable per-CPU IRQs on all CPUs David Daney
2011-01-07  2:35 ` [PATCH 2/6] MIPS: Add accessor macros for 64-bit performance counter registers David Daney
2011-01-07  2:35 ` [PATCH 3/6] MIPS: perf: Cleanup formatting in arch/mips/kernel/perf_event.c David Daney
2011-01-07  2:35 ` [PATCH 4/6] MIPS: perf: Reorganize contents of perf support files David Daney
2011-01-20 10:01   ` Deng-Cheng Zhu
2011-01-20 17:51     ` David Daney
2011-01-07  2:35 ` [PATCH 5/6] MIPS: perf: Add support for 64-bit perf counters David Daney
2011-01-20 10:06   ` Deng-Cheng Zhu
2011-01-20 17:48     ` David Daney
2011-01-07  2:35 ` [PATCH 6/6] MIPS: perf: Add Octeon support for hardware perf David Daney
2011-01-20  9:59 ` [PATCH 0/6] MIPS: perf: Make perf work for 64-bit/Octeon counters Deng-Cheng Zhu
2011-01-20 17:55   ` David Daney
2011-01-22  0:17   ` David Daney [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D3A2231.1040802@caviumnetworks.com \
    --to=ddaney@caviumnetworks.com \
    --cc=dengcheng.zhu@gmail.com \
    --cc=linux-mips@linux-mips.org \
    --cc=ralf@linux-mips.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.