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