How to get better precision out of getrusage on the ARM?
Yang, Wenyou
Wenyou.Yang at atmel.com
Tue Jan 19 17:24:31 PST 2016
Hi Patrick,
Add Cyrille in loop, Cyrille is a timer guru in our company.
> -----Original Message-----
> From: Patrick Doyle [mailto:wpdster at gmail.com]
> Sent: 2016年1月19日 22:37
> To: Yang, Wenyou <Wenyou.Yang at atmel.com>
> Cc: Corey Minyard <tcminyard at gmail.com>; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: How to get better precision out of getrusage on the ARM?
>
> 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.
Thank you for your information.
>
> 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.
Please send me your patch, having it, we will have a good point to investigate it.
As you known, we are spending time on this issue.
Don't worry.
Thanks.
Best Regards,
Wenyou Yang
More information about the linux-arm-kernel
mailing list