Re: oprofile and ARM A9 hardware counter

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

Ok, with the one-line patch [1], this works much better now.
No more wrap around a 4 billion cycles.

Sampling is okay, though I noticed it tends to not get the
correct number of samples for a controlled run:

$ perf record -e cycles -c 1009213 noploop 10
noploop for 10 seconds

$ perf report -D | tail -20
cycles stats:
           TOTAL events:       9938
            MMAP events:         13
            COMM events:          2
            EXIT events:          2
        THROTTLE events:         12
      UNTHROTTLE events:         12
          SAMPLE events:       9897

Should not get throttled samples. Should get abour 10k samples
but only seeing 9897. The max_rate limit is way higher
than what I set the period (1000 samples/sec). But then,
is 3.2.0 throttling is broken. I posted a patch to fix that
yesterday. I will try with my patch applied as well.


Will do some more testing and update to the latest 3.3.0-rc1.
For now this is with 3.2.0 Linus tree.

$ sudo  ./syst_count -c 1 -p -e cpu_cycles
<press CTRL-C to quit before 20s time limit>
# 1s -----
CPU1   G0  1008360963           cpu_cycles (scaling 0.00%,
ena=1000427246, run=1000427246)
# 2s -----
CPU1   G0  2016503406           cpu_cycles (scaling 0.00%,
ena=2000610351, run=2000610351)
# 3s -----
CPU1   G0  3024622201           cpu_cycles (scaling 0.00%,
ena=3000701904, run=3000701904)
# 4s -----
CPU1   G0  4032753756           cpu_cycles (scaling 0.00%,
ena=4000823974, run=4000823974)
# 5s -----
CPU1   G0  5041040463           cpu_cycles (scaling 0.00%,
ena=5001098633, run=5001098633)
# 6s -----
CPU1   G0  6049184665           cpu_cycles (scaling 0.00%,
ena=6001220703, run=6001220703)
# 7s -----
CPU1   G0  7057336298           cpu_cycles (scaling 0.00%,
ena=7001403808, run=7001403808)
# 8s -----
CPU1   G0  8065459152           cpu_cycles (scaling 0.00%,
ena=8001556395, run=8001556395)
# 9s -----
CPU1   G0  9074297578           cpu_cycles (scaling 0.00%,
ena=9002380370, run=9002380370)
# 10s -----
CPU1   G0  10082619086          cpu_cycles (scaling 0.00%,
ena=10003540038, run=10003540038)

On Fri, Jan 27, 2012 at 3:09 PM, Ming Lei <ming.lei@xxxxxxxxxxxxx> wrote:
> Hi,
>
> 2012/1/27 Will Deacon <will.deacon@xxxxxxx>:
>> Mans,
>>
>> On Fri, Jan 27, 2012 at 12:56:35PM +0000, Måns Rullgård wrote:
>>> Will Deacon <will.deacon@xxxxxxx> writes:
>>> > Did this lead anywhere in the end? It seems as though Ming Lei has a working
>>> > setup but Stephane is unable to replicate it, despite applying the necessary
>>> > patches and trying an updated bootloader.
>>>
>>> With the patches listed above plus the one in [1], I get PMU interrupts.
>>> However, unless I restrict the profiled process to one CPU
>>> (taskset 1 perf record ...), I get a panic in armpmu_event_update() with
>>> the 'event' argument being null when called from armv7pmu_handle_irq().
>>>
>>> [1] http://article.gmane.org/gmane.linux.ports.arm.omap/69696
>>
>> Great, thanks for trying this out. Which version of the kernel were you
>> using?
>
> The patch is required for 3.3-rc1 in case that omap4 pmu works well.
>
> thanks,
> --
> Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux