From mboxrd@z Thu Jan 1 00:00:00 1970 From: tcminyard@gmail.com (Corey Minyard) Date: Wed, 20 Jan 2016 08:35:08 -0600 Subject: How to get better precision out of getrusage on the ARM? In-Reply-To: References: <20151222144907.GK8644@n2100.arm.linux.org.uk> <20151222151314.GM8644@n2100.arm.linux.org.uk> <5686C211.5040606@gmail.com> <569DC0B3.6070804@atmel.com> Message-ID: <569F9B1C.4010806@gmail.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 01/19/2016 08:36 AM, Patrick Doyle wrote: > On Mon, Jan 18, 2016 at 11:50 PM, Yang, Wenyou 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