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

Corey Minyard tcminyard at
Wed Jan 20 06:35:08 PST 2016

On 01/19/2016 08:36 AM, Patrick Doyle wrote:
> On Mon, Jan 18, 2016 at 11:50 PM, Yang, Wenyou <wenyou.yang at> wrote:
>> On 2016/1/2 2:14, Corey Minyard wrote:
>>> I have some patches at 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 
you may want to look at those.


> 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
> 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

More information about the linux-arm-kernel mailing list