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

[Yang, Wenyou]

Hi Patrick,

On 2016/1/2 2:14, Corey Minyard wrote:
> 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.

I want to run this similar tests on my side.

It seems you don't use this project. What project do you use as your 
application?  Could you give some information?

Did your questions resolve?  What is remaining?

Thank you!

>
> -corey
>
> On 12/30/2015 09:52 AM, Patrick Doyle wrote:
>> On Wed, Dec 30, 2015 at 10:00 AM, Patrick Doyle <wpdster at gmail.com> 
>> wrote:
>>> 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
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


Best Regards,
Wenyou Yang