oprofile and ARM A9 hardware counter

Ming Lei ming.lei at canonical.com
Thu Jan 19 07:45:04 EST 2012


Hi,

On Thu, Jan 19, 2012 at 7:34 PM, stephane eranian
<eranian at googlemail.com> wrote:
> Hi,
>
> Ok some update on this.
> With your .config file + 3.2.0 (Linus) + patch 3, 4, 5, 6, I get a kernel that

You forget patch 1 and patch 2?

> boots. It does recognize the PMU. However, it still does not count correctly
> and I believe for the same reason.: no interrupts are delivered.
>
> I run a cycle burner program on CPU0, I watch /proc/interrupts.
> and then I run  libpfm4 program that does per-cpu monitoring on CPU0 and
> print the counts every second:

I just run 'perf top', then watch output of '/proc/interrupts' in
another terminal. I am sure I can see perf is OK and interrupts are
generated on my pandaboard.

>
> $ sudo ./syst_count -d 10 -p -c 0 -e cpu_cycles
> <press CTRL-C to quit before 10s time limit>
> # 1s -----
> CPU0   G0  1008129147           cpu_cycles (scaling 0.00%,
> ena=1000152588, run=1000152588)
> # 2s -----
> CPU0   G0  2016240766           cpu_cycles (scaling 0.00%,
> ena=2000335693, run=2000335693)
> # 3s -----
> CPU0   G0  3024249265           cpu_cycles (scaling 0.00%,
> ena=3000427245, run=3000427245)
> # 4s -----
> CPU0   G0  4072779364           cpu_cycles (scaling 0.00%,
> ena=4040710449, run=4040710449)
> # 5s -----
> CPU0   G0  785954705            cpu_cycles (scaling 0.00%,
> ena=5040954589, run=5040954589)
> # 6s -----
> CPU0   G0  1803397848           cpu_cycles (scaling 0.00%,
> ena=6050384520, run=6050384520)
> # 7s -----
>
> You clearly see that after 4s you've reached the 32-bit limit of the
> counter and then you wrap around.
> It should show 5 billions or so cycles. Over the entire run, no
> arm-pmu interrupt was delivered according
> to /proc/interrupts.
>
> I guess you can test the same condition using perf directly, use a
> program that burns cycles
> for a know duration. Try < 4s and then > 4s. I use 1s vs. 10s and I
> expect the count to be
> 10x larger in the latter test case. If it's not then, interrupts are
> not coming in,
>
>
> On Thu, Jan 19, 2012 at 2:21 AM, Ming Lei <ming.lei at canonical.com> wrote:
>> Hi,
>>
>> On Thu, Jan 19, 2012 at 5:58 AM, stephane eranian
>> <eranian at googlemail.com> wrote:
>>> Ming,
>>>
>>> Ok, so I used Linus' tree @
>>>
>>> It already includes patches #1 and #2. I applied 4-6.
>>
>> The patch #3 is missed?
>>
>>> Recompiled but my kernel does not boot, I don't see
>>> anything on the serial console. Could be a broken
>>
>> I don't think that the patches can cause your non boot, you
>> can try the linus tree kernel first, then try the patches.
>>
>>> .config file. Could you send me your .config for Panda?
>>
>> See the attachment.
>>
>>>
>>> Thanks.
>>>
>>> On Wed, Jan 18, 2012 at 11:07 AM, Ming Lei <ming.lei at canonical.com> wrote:
>>>> Hi,
>>>>
>>>> On Wed, Jan 18, 2012 at 5:54 PM, stephane eranian <eranian at googlemail.com>
>>>>> Should I use Will's -next tree as the base instead of Linus'?
>>>>
>>>> Either one is OK. If you use linus tree as base, you need to apply the #1 and
>>>> #2 patch manually.
>>>>
>>>>> Given that MARC is shutdown today, would you mind packing those patches
>>>>> into a tarball and sending them to me directly?
>>>>
>>>> See attachment, which includes the patches from #3 to #6.
>>>>
>>>>>
>>>>> When you mention Will's -next tree, are you talking about:
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git for-next/perf
>>>>
>>>> It is perf/omap4 brach, you can pick up the two patches[1][2] directly from
>>>> the branch.
>>>>
>>>>
>>>> thanks,
>>>> --
>>>> Ming Lei
>>>>
>>>> [1], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=7924a3eba0766348d6d6a56cbb9873cdbcab0d8c
>>>>
>>>> [2], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=bde071f005e2dc71378aff69e86b961d8cd7922f
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>>> the body of a message to majordomo at vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



More information about the linux-arm-kernel mailing list