How to get better precision out of getrusage on the ARM?
tcminyard at gmail.com
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 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
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
> (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.
More information about the linux-arm-kernel