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
