oprofile and ARM A9 hardware counter

[stephane eranian]

Hi,

Ok some update on this.
With your .config file + 3.2.0 (Linus) + patch 3, 4, 5, 6, I get a kernel that
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:

$ 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