Hi all,
Say has anyone else run oprofile on recent builds on panda?
By recent I mean say anything since 11.07? Reason for asking is I'm seeing basically a very very small number of samples being recorded... as in there's no way this is right.
Log:
root@linaro-desktop:/home/linaro/ltj-1.1.90-d# opcontrol --reset Signalling daemon... done root@linaro-desktop:/home/linaro/ltj-1.1.90-d# opcontrol --start Profiler running. root@linaro-desktop:/home/linaro/ltj-1.1.90-d# ./djpeg ~linaro/Saturn.jpg > /dev/null Decoding took 1216 ms root@linaro-desktop:/home/linaro/ltj-1.1.90-d# ./djpeg ~linaro/Saturn.jpg > /dev/null Decoding took 1206 ms root@linaro-desktop:/home/linaro/ltj-1.1.90-d# root@linaro-desktop:/home/linaro/ltj-1.1.90-d# ./djpeg ~linaro/Saturn.jpg > /dev/null Decoding took 1207 ms root@linaro-desktop:/home/linaro/ltj-1.1.90-d# ./djpeg ~linaro/Saturn.jpg > /dev/null Decoding took 1212 ms root@linaro-desktop:/home/linaro/ltj-1.1.90-d# opcontrol --stop Stopping profiling. root@linaro-desktop:/home/linaro/ltj-1.1.90-d# opreport -l ./djpeg Overflow stats not available CPU: CPU with timer interrupt, speed 0 MHz (estimated) Profiling through timer interrupt samples % symbol name 1 100.000 put_pixel_rows
I'll pull the latest and retry still, this I think is the11.07 ubuntu-desktop LEB release for panda (or pretty close) uname -a Linux linaro-desktop 3.0.0-1001-linaro-omap #1~ppa~natty-Ubuntu SMP PREEMPT Mon Jul 25 22:44:36 UTC 2011 armv7l armv7l armv7l GNU/Linux
Thanks!
On Friday 26 August 2011 03:18 AM, Tom Gall wrote:
Hi all,
Say has anyone else run oprofile on recent builds on panda?
By recent I mean say anything since 11.07? Reason for asking is I'm seeing basically a very very small number of samples being recorded... as in there's no way this is right.
Log:
root@linaro-desktop:/home/linaro/ltj-1.1.90-d# opcontrol --reset Signalling daemon... done root@linaro-desktop:/home/linaro/ltj-1.1.90-d# opcontrol --start Profiler running. root@linaro-desktop:/home/linaro/ltj-1.1.90-d# ./djpeg ~linaro/Saturn.jpg > /dev/null Decoding took 1216 ms root@linaro-desktop:/home/linaro/ltj-1.1.90-d# ./djpeg ~linaro/Saturn.jpg > /dev/null Decoding took 1206 ms root@linaro-desktop:/home/linaro/ltj-1.1.90-d# root@linaro-desktop:/home/linaro/ltj-1.1.90-d# ./djpeg ~linaro/Saturn.jpg > /dev/null Decoding took 1207 ms root@linaro-desktop:/home/linaro/ltj-1.1.90-d# ./djpeg ~linaro/Saturn.jpg > /dev/null Decoding took 1212 ms root@linaro-desktop:/home/linaro/ltj-1.1.90-d# opcontrol --stop Stopping profiling. root@linaro-desktop:/home/linaro/ltj-1.1.90-d# opreport -l ./djpeg Overflow stats not available CPU: CPU with timer interrupt, speed 0 MHz (estimated) Profiling through timer interrupt samples % symbol name 1 100.000 put_pixel_rows
Is it because oprofile is profiling through timer interrupt and not through pmu counter like CPU_CYCLES? One reason for not using pmu counters could be lack of support for pmu in omap4 as the pmu patch has been removed from linux-linaro-2.6.39 (https://bugs.launchpad.net/linux-linaro/+bug/802693) onwards that affected 11.07+ images.
Regards, Avik
On Thu, Aug 25, 2011 at 11:48 PM, Tom Gall tom.gall@linaro.org wrote:
Say has anyone else run oprofile on recent builds on panda?
By recent I mean say anything since 11.07? Reason for asking is I'm seeing basically a very very small number of samples being recorded... as in there's no way this is right.
depending on the kernel config, oprofile might just try to use the h/w counter by default and it does not work. try adding "oprofile.timer=1" in the bootargs. that should work better
Thanks.
I'll give that a try. Still, oprofile ought to work out of the box without fiddling.
Regards, Tom
On Fri, Aug 26, 2011 at 5:04 AM, Dechesne, Nicolas n-dechesne@ti.com wrote:
On Thu, Aug 25, 2011 at 11:48 PM, Tom Gall tom.gall@linaro.org wrote:
Say has anyone else run oprofile on recent builds on panda?
By recent I mean say anything since 11.07? Reason for asking is I'm seeing basically a very very small number of samples being recorded... as in there's no way this is right.
depending on the kernel config, oprofile might just try to use the h/w counter by default and it does not work. try adding "oprofile.timer=1" in the bootargs. that should work better
On Fri, Aug 26, 2011 at 6:10 PM, Tom Gall tom.gall@linaro.org wrote:
I'll give that a try. Still, oprofile ought to work out of the box without fiddling
agreed. if that works, you will need to add that in default bootargs, or update the defconfig.
On Fri, Aug 26, 2011 at 11:10:11AM -0500, Tom Gall wrote:
I'll give that a try. Still, oprofile ought to work out of the box without fiddling.
That's exactly how I feel. If Nicolas is right, what causes this to depend on the kernel's counter selection, and why can't we figure out what to use in runtime?
An update on my oprofile adventures with panda.
I did add the kernel param as Nicolas suggested and am getting a little more data out of oprofile on panda but it's still pretty awful as the resolution of the samples is quite poor.
This data for instance was gathered over 5 runs of djpeg crunching on a 1920x1280 jpeg image:
CPU: CPU with timer interrupt, speed 0 MHz (estimated) Profiling through timer interrupt samples % image name symbol name 29 34.5238 libjpeg.so.62.0.0 decode_mcu 27 32.1429 libjpeg.so.62.0.0 h2v2_fancy_upsample 8 9.5238 libjpeg.so.62.0.0 jsimd_idct_islow_neon 7 8.3333 libc-2.13.so /lib/arm-linux-gnueabi/libc-2.13.so 7 8.3333 libjpeg.so.62.0.0 jsimd_ycc_extrgb_convert_neon 4 4.7619 libjpeg.so.62.0.0 decompress_onepass 1 1.1905 libjpeg.so.62.0.0 sep_upsample 1 1.1905 no-vmlinux /no-vmlinux
That's not a lot of samples given the time involved. Worse there's no way to adjust the timer up or down to adjust the number of samples being captured. It really hurts the usefulness of oprofile for looking at performance problems in user space code on arm which is what I'm trying to do in support of the upstream libjpeg-turbo community.
Siarhei Siamashka for instance has also noted this. See http://ssvb.github.com/2011/08/23/yet-another-oprofile-tutorial.html (scan down to ARM Cortex-A8 performance monitoring)
Not being wise to latest greatest in oprofile kernel mods, perhaps there's already a solution here... if so I'd love to hear it.
On Mon, Aug 29, 2011 at 9:23 AM, Christian Robottom Reis kiko@linaro.org wrote:
On Fri, Aug 26, 2011 at 11:10:11AM -0500, Tom Gall wrote:
I'll give that a try. Still, oprofile ought to work out of the box without fiddling.
That's exactly how I feel. If Nicolas is right, what causes this to depend on the kernel's counter selection, and why can't we figure out what to use in runtime? -- Christian Robottom Reis, Engineering VP Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 Linaro.org: Open Source Software for ARM SoCs
Could you try also adding 'nohz=0' to bootargs to disable tickless scheduler? Depending on what is the default in current linaro kernel, this might help..
BR, -R
On Mon, Aug 29, 2011 at 1:57 PM, Tom Gall tom.gall@linaro.org wrote:
An update on my oprofile adventures with panda.
I did add the kernel param as Nicolas suggested and am getting a little more data out of oprofile on panda but it's still pretty awful as the resolution of the samples is quite poor.
This data for instance was gathered over 5 runs of djpeg crunching on a 1920x1280 jpeg image:
CPU: CPU with timer interrupt, speed 0 MHz (estimated) Profiling through timer interrupt samples % image name symbol name 29 34.5238 libjpeg.so.62.0.0 decode_mcu 27 32.1429 libjpeg.so.62.0.0 h2v2_fancy_upsample 8 9.5238 libjpeg.so.62.0.0 jsimd_idct_islow_neon 7 8.3333 libc-2.13.so /lib/arm-linux-gnueabi/libc-2.13.so 7 8.3333 libjpeg.so.62.0.0 jsimd_ycc_extrgb_convert_neon 4 4.7619 libjpeg.so.62.0.0 decompress_onepass 1 1.1905 libjpeg.so.62.0.0 sep_upsample 1 1.1905 no-vmlinux /no-vmlinux
That's not a lot of samples given the time involved. Worse there's no way to adjust the timer up or down to adjust the number of samples being captured. It really hurts the usefulness of oprofile for looking at performance problems in user space code on arm which is what I'm trying to do in support of the upstream libjpeg-turbo community.
Siarhei Siamashka for instance has also noted this. See http://ssvb.github.com/2011/08/23/yet-another-oprofile-tutorial.html (scan down to ARM Cortex-A8 performance monitoring)
Not being wise to latest greatest in oprofile kernel mods, perhaps there's already a solution here... if so I'd love to hear it.
On Mon, Aug 29, 2011 at 9:23 AM, Christian Robottom Reis kiko@linaro.org wrote:
On Fri, Aug 26, 2011 at 11:10:11AM -0500, Tom Gall wrote:
I'll give that a try. Still, oprofile ought to work out of the box without fiddling.
That's exactly how I feel. If Nicolas is right, what causes this to depend on the kernel's counter selection, and why can't we figure out what to use in runtime? -- Christian Robottom Reis, Engineering VP Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 Linaro.org: Open Source Software for ARM SoCs
-- Regards, Tom
"We want great men who, when fortune frowns will not be discouraged."
- Colonel Henry Knox
Linaro.org │ Open source software for ARM SoCs w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Thanks Rob for the suggestion.
Same number of runs as last time, same data file as well of course.
PU: CPU with timer interrupt, speed 0 MHz (estimated) Profiling through timer interrupt samples % image name symbol name 35 40.2299 libjpeg.so.62.0.0 decode_mcu 17 19.5402 libjpeg.so.62.0.0 h2v2_fancy_upsample 10 11.4943 no-vmlinux /no-vmlinux 8 9.1954 libjpeg.so.62.0.0 jsimd_idct_islow_neon 7 8.0460 libjpeg.so.62.0.0 jsimd_ycc_extrgb_convert_neon 5 5.7471 libc-2.13.so /lib/arm-linux-gnueabi/libc-2.13.so 3 3.4483 libjpeg.so.62.0.0 jpeg_fill_bit_buffer 1 1.1494 libjpeg.so.62.0.0 decompress_onepass 1 1.1494 libjpeg.so.62.0.0 sep_upsample
84 samples oprofile.timer=1
87 samples. oprofile.timer=1 nohz=0
On Mon, Aug 29, 2011 at 7:29 PM, Clark, Rob rob@ti.com wrote:
Could you try also adding 'nohz=0' to bootargs to disable tickless scheduler? Depending on what is the default in current linaro kernel, this might help..
BR, -R
On Mon, Aug 29, 2011 at 1:57 PM, Tom Gall tom.gall@linaro.org wrote:
An update on my oprofile adventures with panda.
I did add the kernel param as Nicolas suggested and am getting a little more data out of oprofile on panda but it's still pretty awful as the resolution of the samples is quite poor.
This data for instance was gathered over 5 runs of djpeg crunching on a 1920x1280 jpeg image:
CPU: CPU with timer interrupt, speed 0 MHz (estimated) Profiling through timer interrupt samples % image name symbol name 29 34.5238 libjpeg.so.62.0.0 decode_mcu 27 32.1429 libjpeg.so.62.0.0 h2v2_fancy_upsample 8 9.5238 libjpeg.so.62.0.0 jsimd_idct_islow_neon 7 8.3333 libc-2.13.so /lib/arm-linux-gnueabi/libc-2.13.so 7 8.3333 libjpeg.so.62.0.0 jsimd_ycc_extrgb_convert_neon 4 4.7619 libjpeg.so.62.0.0 decompress_onepass 1 1.1905 libjpeg.so.62.0.0 sep_upsample 1 1.1905 no-vmlinux /no-vmlinux
That's not a lot of samples given the time involved. Worse there's no way to adjust the timer up or down to adjust the number of samples being captured. It really hurts the usefulness of oprofile for looking at performance problems in user space code on arm which is what I'm trying to do in support of the upstream libjpeg-turbo community.
Siarhei Siamashka for instance has also noted this. See http://ssvb.github.com/2011/08/23/yet-another-oprofile-tutorial.html (scan down to ARM Cortex-A8 performance monitoring)
Not being wise to latest greatest in oprofile kernel mods, perhaps there's already a solution here... if so I'd love to hear it.
On Mon, Aug 29, 2011 at 9:23 AM, Christian Robottom Reis kiko@linaro.org wrote:
On Fri, Aug 26, 2011 at 11:10:11AM -0500, Tom Gall wrote:
I'll give that a try. Still, oprofile ought to work out of the box without fiddling.
That's exactly how I feel. If Nicolas is right, what causes this to depend on the kernel's counter selection, and why can't we figure out what to use in runtime? -- Christian Robottom Reis, Engineering VP Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 Linaro.org: Open Source Software for ARM SoCs
-- Regards, Tom
"We want great men who, when fortune frowns will not be discouraged."
- Colonel Henry Knox
Linaro.org │ Open source software for ARM SoCs w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Hi,
As indicated by Siamashka, we are expected to operate at scheduler tick rate, i.e. 128Hz (drivers/oprofile/timer_int.c). From your test, we have 84 ticks, i.e. 656ms of test. Is that correct ? I checked that also in our Android kernel and it was the same.
The only impacts we have seen in the past are related to idle time. For same duration, we had less ticks if more idle time. But Android guys, who used it more than us, never really complained on this or timer granularity. Probably this was more orented to multimedia use cases so 10s of s.
Regards Fred
Frederic Turgis OMAP Platform Business Unit - OMAP System Engineering - Platform Enablement
Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920
-----Original Message-----
From: linaro-dev-bounces@lists.linaro.org [mailto:linaro-dev-bounces@lists.linaro.org] On Behalf Of Clark, Rob Sent: Tuesday, August 30, 2011 2:30 AM To: Tom Gall Cc: Linaro Dev Subject: Re: 11.07 oprofile on panda busted?
Could you try also adding 'nohz=0' to bootargs to disable tickless scheduler? Depending on what is the default in current linaro kernel, this might help..
BR, -R
On Mon, Aug 29, 2011 at 1:57 PM, Tom Gall tom.gall@linaro.org wrote:
An update on my oprofile adventures with panda.
I did add the kernel param as Nicolas suggested and am getting a little more data out of oprofile on panda but it's still
pretty awful
as the resolution of the samples is quite poor.
This data for instance was gathered over 5 runs of djpeg
crunching on
a 1920x1280 jpeg image:
CPU: CPU with timer interrupt, speed 0 MHz (estimated) Profiling through timer interrupt samples % image name symbol name 29 34.5238 libjpeg.so.62.0.0 decode_mcu 27 32.1429 libjpeg.so.62.0.0 h2v2_fancy_upsample 8 9.5238 libjpeg.so.62.0.0 jsimd_idct_islow_neon 7 8.3333 libc-2.13.so /lib/arm-linux-gnueabi/libc-2.13.so 7 8.3333 libjpeg.so.62.0.0 jsimd_ycc_extrgb_convert_neon 4 4.7619 libjpeg.so.62.0.0 decompress_onepass 1 1.1905 libjpeg.so.62.0.0 sep_upsample 1 1.1905 no-vmlinux /no-vmlinux
That's not a lot of samples given the time involved. Worse
there's no
way to adjust the timer up or down to adjust the number of samples being captured. It really hurts the usefulness of oprofile
for looking
at performance problems in user space code on arm which is what I'm trying to do in support of the upstream libjpeg-turbo community.
Siarhei Siamashka for instance has also noted this. See http://ssvb.github.com/2011/08/23/yet-another-oprofile-tutorial.html (scan down to ARM Cortex-A8 performance monitoring)
Not being wise to latest greatest in oprofile kernel mods, perhaps there's already a solution here... if so I'd love to hear it.
On Mon, Aug 29, 2011 at 9:23 AM, Christian Robottom Reis kiko@linaro.org wrote:
On Fri, Aug 26, 2011 at 11:10:11AM -0500, Tom Gall wrote:
I'll give that a try. Still, oprofile ought to work out
of the box
without fiddling.
That's exactly how I feel. If Nicolas is right, what
causes this to
depend on the kernel's counter selection, and why can't we figure out what to use in runtime? -- Christian Robottom Reis, Engineering VP Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 Linaro.org: Open Source Software for ARM SoCs
-- Regards, Tom
"We want great men who, when fortune frowns will not be
discouraged."
- Colonel Henry Knox
Linaro.org ¦ Open source software for ARM SoCs w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On Tue, Aug 30, 2011 at 10:53 AM, Turgis, Frederic f-turgis@ti.com wrote:
Hi,
As indicated by Siamashka, we are expected to operate at scheduler tick rate, i.e. 128Hz (drivers/oprofile/timer_int.c). From your test, we have 84 ticks, i.e. 656ms of test. Is that correct ? I checked that also in our Android kernel and it was the same.
Makes sense, but it brings me back to my earlier lament, that a user tunable option to up the rate for the purpose of collecting more samples would be quite desirable.
The only impacts we have seen in the past are related to idle time. For same duration, we had less ticks if more idle time. But Android guys, who used it more than us, never really complained on this or timer granularity. Probably this was more orented to multimedia use cases so 10s of s.
Regards Fred
Frederic Turgis OMAP Platform Business Unit - OMAP System Engineering - Platform Enablement
Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920
Hi,
I could suggest to run 10 times the test in a row ;-) but oprofile clearly relies on a configurable timer and not the scheduler tick itself so there is no reason for this limitation, as this is not a rewrite. For example x86 has a CONFIG_OPROFILE_EVENT_MULTIPLEX feature for which developers added /dev/oprofile/time_slice for tuning so no religion here. Probably inherited from the past where platforms were less powerful.
FYI, oprofile "file operations" are set in arch/arm/oprofile/common.c, leveraging ARM Performance Monitoring Unit. But if oprofile.timer is set, oprofile functions are redefined to leverage generic hrtimer. PMU can lose interrupt when register overflows (ARM errata), current potential work-around is to use several counters for same event so that at least 1 of them catches the info :-( not very reliable => so oprofile.timer = 1 shall be the default.
Regards Fred
Frederic Turgis OMAP Platform Business Unit - OMAP System Engineering - Platform Enablement
Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920
-----Original Message-----
From: Tom Gall [mailto:tom.gall@linaro.org] Sent: Tuesday, August 30, 2011 6:03 PM To: Turgis, Frederic Cc: Clark, Rob; Linaro Dev Subject: Re: 11.07 oprofile on panda busted?
On Tue, Aug 30, 2011 at 10:53 AM, Turgis, Frederic f-turgis@ti.com wrote:
Hi,
As indicated by Siamashka, we are expected to operate at
scheduler tick rate, i.e. 128Hz (drivers/oprofile/timer_int.c). From your test, we have 84 ticks, i.e. 656ms of test.
Is that correct ? I checked that also in our Android kernel
and it was the same.
Makes sense, but it brings me back to my earlier lament, that a user tunable option to up the rate for the purpose of collecting more samples would be quite desirable.
The only impacts we have seen in the past are related to
idle time. For same duration, we had less ticks if more idle time. But Android guys, who used it more than us, never really complained on this or timer granularity. Probably this was more orented to multimedia use cases so 10s of s.
Regards Fred
Frederic Turgis OMAP Platform Business Unit - OMAP System Engineering - Platform Enablement
Texas Instruments France SA, 821 Avenue Jack Kilby, 06270
Villeneuve
Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920
-- Regards, Tom
"We want great men who, when fortune frowns will not be discouraged."
- Colonel Henry Knox
Linaro.org ¦ Open source software for ARM SoCs w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com
On Thu, Aug 25, 2011 at 04:48:57PM -0500, Tom Gall wrote:
Hi all,
Say has anyone else run oprofile on recent builds on panda?
By recent I mean say anything since 11.07? Reason for asking is I'm seeing basically a very very small number of samples being recorded... as in there's no way this is right.
These days, I believe the separate oprofile backend for ARM has gone away, and oprofile is implemented using the perf backend anyway.
So, perhaps a more interesting question is: does perf work?
See whether this works:
apt-get install linux-linaro-tools-`uname -r` perf stat apt-get update # or something
I think there was an issue with a patch which enabled perf on omap4 but broke it on all other platforms. This patch is present in the linux-linaro-natty tree, but I can't see it in -oneiric. I think it may have been dropped / backed out from the oneiric tree because of the problems it caused:
In linux-linaro-natty/master: commit 457520e3fbce80812c6901c226ec242fdb906c63 (arm: pmu: support pmu/perf on OMAP4)
Mark Rutland posted a patch to fix the introduced problem -- search the linaro-dev archives for [PATCH] Fix NULL-dereference introduced by OMAP4 PMU patch
...however, I don't know whether or not this is still relevant.
If perf works but oprofile doesn't, that's a separate problem and should be investigated. You might want to consider switching to perf anyway though -- in my experience it's less problem-prone than using oprofile.
Cheers ---Dave
Log:
root@linaro-desktop:/home/linaro/ltj-1.1.90-d# opcontrol --reset Signalling daemon... done root@linaro-desktop:/home/linaro/ltj-1.1.90-d# opcontrol --start Profiler running. root@linaro-desktop:/home/linaro/ltj-1.1.90-d# ./djpeg ~linaro/Saturn.jpg > /dev/null Decoding took 1216 ms root@linaro-desktop:/home/linaro/ltj-1.1.90-d# ./djpeg ~linaro/Saturn.jpg > /dev/null Decoding took 1206 ms root@linaro-desktop:/home/linaro/ltj-1.1.90-d# root@linaro-desktop:/home/linaro/ltj-1.1.90-d# ./djpeg ~linaro/Saturn.jpg > /dev/null Decoding took 1207 ms root@linaro-desktop:/home/linaro/ltj-1.1.90-d# ./djpeg ~linaro/Saturn.jpg > /dev/null Decoding took 1212 ms root@linaro-desktop:/home/linaro/ltj-1.1.90-d# opcontrol --stop Stopping profiling. root@linaro-desktop:/home/linaro/ltj-1.1.90-d# opreport -l ./djpeg Overflow stats not available CPU: CPU with timer interrupt, speed 0 MHz (estimated) Profiling through timer interrupt samples % symbol name 1 100.000 put_pixel_rows
I'll pull the latest and retry still, this I think is the11.07 ubuntu-desktop LEB release for panda (or pretty close) uname -a Linux linaro-desktop 3.0.0-1001-linaro-omap #1~ppa~natty-Ubuntu SMP PREEMPT Mon Jul 25 22:44:36 UTC 2011 armv7l armv7l armv7l GNU/Linux
Thanks!
-- Regards, Tom
"We want great men who, when fortune frowns will not be discouraged."
- Colonel Henry Knox
Linaro.org │ Open source software for ARM SoCs w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On Wednesday 31 August 2011 08:26 PM, Dave Martin wrote:
On Thu, Aug 25, 2011 at 04:48:57PM -0500, Tom Gall wrote:
Hi all,
Say has anyone else run oprofile on recent builds on panda?
By recent I mean say anything since 11.07? Reason for asking is I'm seeing basically a very very small number of samples being recorded... as in there's no way this is right.
These days, I believe the separate oprofile backend for ARM has gone away, and oprofile is implemented using the perf backend anyway.
So, perhaps a more interesting question is: does perf work?
See whether this works:
apt-get install linux-linaro-tools-`uname -r` perf stat apt-get update # or something
I think there was an issue with a patch which enabled perf on omap4 but broke it on all other platforms. This patch is present in the linux-linaro-natty tree, but I can't see it in -oneiric. I think it may have been dropped / backed out from the oneiric tree because of the problems it caused:
In linux-linaro-natty/master: commit 457520e3fbce80812c6901c226ec242fdb906c63 (arm: pmu: support pmu/perf on OMAP4)
The perf patch was dropped from linux-linaro-2.6.39 onwards as it apparently caused Panda boot hang (https://bugs.launchpad.net/linux-linaro/+bug/802693).
Mark Rutland posted a patch to fix the introduced problem -- search the linaro-dev archives for [PATCH] Fix NULL-dereference introduced by OMAP4 PMU patch
...however, I don't know whether or not this is still relevant.
If perf works but oprofile doesn't, that's a separate problem and should be investigated. You might want to consider switching to perf anyway though -- in my experience it's less problem-prone than using oprofile.
Cheers ---Dave
Regards, Avik
On Fri, Sep 02, 2011 at 05:22:35PM +0530, Avik Sil wrote:
See whether this works:
apt-get install linux-linaro-tools-`uname -r` perf stat apt-get update # or something
I think there was an issue with a patch which enabled perf on omap4 but broke it on all other platforms. This patch is present in the linux-linaro-natty tree, but I can't see it in -oneiric. I think it may have been dropped / backed out from the oneiric tree because of the problems it caused:
In linux-linaro-natty/master: commit 457520e3fbce80812c6901c226ec242fdb906c63 (arm: pmu: support pmu/perf on OMAP4)
The perf patch was dropped from linux-linaro-2.6.39 onwards as it apparently caused Panda boot hang (https://bugs.launchpad.net/linux-linaro/+bug/802693).
Mark Rutland posted a patch to fix the introduced problem -- search the linaro-dev archives for [PATCH] Fix NULL-dereference introduced by OMAP4 PMU patch
Avik, because of your quoting style I'm not sure you are ignoring Dave's point here or if you are saying that there was a further problem that caused the entire patch to be dropped? See
http://www.mail-archive.com/linaro-dev@lists.linaro.org/msg04791.html
On Saturday 03 September 2011 12:16 AM, Christian Robottom Reis wrote:
On Fri, Sep 02, 2011 at 05:22:35PM +0530, Avik Sil wrote:
See whether this works:
apt-get install linux-linaro-tools-`uname -r` perf stat apt-get update # or something
I think there was an issue with a patch which enabled perf on omap4 but broke it on all other platforms. This patch is present in the linux-linaro-natty tree, but I can't see it in -oneiric. I think it may have been dropped / backed out from the oneiric tree because of the problems it caused:
In linux-linaro-natty/master: commit 457520e3fbce80812c6901c226ec242fdb906c63 (arm: pmu: support pmu/perf on OMAP4)
The perf patch was dropped from linux-linaro-2.6.39 onwards as it apparently caused Panda boot hang (https://bugs.launchpad.net/linux-linaro/+bug/802693).
Mark Rutland posted a patch to fix the introduced problem -- search the linaro-dev archives for [PATCH] Fix NULL-dereference introduced by OMAP4 PMU patch
Avik, because of your quoting style I'm not sure you are ignoring Dave's point here or if you are saying that there was a further problem that caused the entire patch to be dropped? See
http://www.mail-archive.com/linaro-dev@lists.linaro.org/msg04791.html
Actually, Mark's patch applies on top of the perf patch and as the perf patch has been dropped, Mark's patch is irrelevant now.
Regards, Avik
On Fri, Sep 2, 2011 at 11:52 PM, Avik Sil avik.sil@linaro.org wrote:
On Wednesday 31 August 2011 08:26 PM, Dave Martin wrote:
On Thu, Aug 25, 2011 at 04:48:57PM -0500, Tom Gall wrote:
The perf patch was dropped from linux-linaro-2.6.39 onwards as it apparently caused Panda boot hang (https://bugs.launchpad.net/linux-linaro/+bug/802693).
Sorry, who is working on this and when is it going back in? perf is a significant feature and Panda is a very common board...
-- Michael
-
Avik Sil -
Christian Robottom Reis -
Clark, Rob -
Dave Martin -
Dechesne, Nicolas -
Michael Hope -
Tom Gall -
Turgis, Frederic