How to get better precision out of getrusage on the ARM?

Those numbers are statistical, if a tick occurs while something is 
running, that something is assigned the entire timer tick.  So as you 
have found, you can get some pretty unusual numbers on this, especially 
with short intervals.

I have some patches at https://sourceforge.net/projects/microstate that 
add the ability to do accurate accounting of time, if you really need that.

-corey

On 12/30/2015 09:52 AM, Patrick Doyle wrote:

On Wed, Dec 30, 2015 at 10:00 AM, Patrick Doyle [off-list ref] wrote:

quoted

Continuing on...
I now have a CLOCKSOURCE_OF_DECLARED()'ed 10 MHz clock source running
on my ARM processor (Atmel SAMA5D2 Xplained board).  It registers
itself through sched_clock_register() to provide a high resolution
sched clock.  Once I turned on "Full dynticks CPU time accounting"
(CONFIG_VIRT_CPU_ACCOUNTING_GEN), I was able to get better than jiffy
resolution from my calls to getrusage(RUSAGE_THREAD,..).  But things
still aren't quite right.  I am using getrusage() to provide some
runtime profile information to an existing application (that was
ported to run on Linux instead of a custom RTOS).  I have code that
looks like:

tick()
// commented out code that used to do something
tock()

where tick() & tock() are my profile "start" and "stop" points that
call getrusage() to record and and accumulate time spent between calls
to tick() & tock().  Most of the time, I get a delta of 0 between the
two calls, which I expect.  But occasionally, I get a delta ranging
between 800us and 1000us, which I don't understand at all.  It seems
like my thread is being "charged" for time spent doing something else.
Perhaps an interrupt occurred and its time got charged to my thread;
perhaps a higher priority thread ran for 1ms, I don't know (yet).

Does anybody have any suggestions as to where I might look, or as to
what kernel CONFIG options might make the most sense for an
application such as this?

--wpd

A couple of more (confusing) data points...
- Changing the tick rate to 100Hz results in deltas as extreme as 9400us.
- Using clock_gettime(CLOCK_THREAD_CPUTIME_ID,...) instead of
getrusage(RUSAGE_THREAD,...) gives much more believable numbers in the
15-25us range, but still with a few bizarre excursions to 41, 69, and
172us (for one random test case).

--wpd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel