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-boun...@lists.linaro.org > [mailto:linaro-dev-boun...@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.g...@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 > > <k...@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 > _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
