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

[Corey Minyard]

On 01/19/2016 08:36 AM, Patrick Doyle wrote:
> On Mon, Jan 18, 2016 at 11:50 PM, Yang, Wenyou <wenyou.yang at atmel.com> wrote:
>> On 2016/1/2 2:14, Corey Minyard wrote:
>>> 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?
> Hello Wenyou,
> For my project, I was porting an existing application that ran on a
> custom embedded OS.  Part of that custom embedded OS provided
> per-thread CPU runtime timers.  As I looked around for a mechanism to
> implement that, I found clock_gettime(2) using the
> CLOCK_THREAD_CPUTIME_ID clk_id should provide the same capability in a
> Posix-ly correct manner.

Those numbers are still statistical by default.  It's the same numbers
as getrusage(), just in a POSIX interface.

I forgot, there is a new kernel option may provide what you need. It's
CONFIG_VIRT_CPU_ACCOUNTING_NATIVE.  I have not tested this, but from
the description it may provide what you need.  It's only available on some
arches it appears.  There are some other timekeeping options in 
init/Kconfig,
you may want to look at those.

-corey

> The problem I ran into was the values returned by
> CLOCK_THREAD_CPUTIME_ID were quantized to multiples of the system tick
> frequency.  So I hacked up tcb_clksrc.c to register itself using
> CLOCKSOURCE_OF_DECLARE() and set the appropriate kernel options
> (CONFIG_HIGH_RES_TIMERS and CONFIG_NO_HZ_IDLE, I think, but I can't
> seem to find my notes or config files from that work -- I hate Monday
> mornings, even virtual ones!).  As I noted in my previous email, I am
> not happy with my changes to tcb_clksrc.c and would like the
> opportunity to discuss them with you and your colleagues at Atmel and
> figure out the best way to approach that.  I'm happy to send the
> patches to you, but I don't think they should go into the linux-at91
> tree without a lot more thought applied.
>
> --wpd