This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: accurate gettimeofday_ns() on arm cortex a9 mpcore
- From: Josh Stone <jistone at redhat dot com>
- To: tonyg362 <tonyg3622 at yahoo dot com>
- Cc: systemtap at sourceware dot org
- Date: Thu, 19 Aug 2010 17:53:11 -0700
- Subject: Re: accurate gettimeofday_ns() on arm cortex a9 mpcore
- References: <29486870.post@talk.nabble.com>
On 08/19/2010 02:54 PM, tonyg362 wrote:
>
> Hi,
>
> I'm trying to get some accurate timing information on an NVIDIA Tegra2 board
> (ARM cortex a9 mpcore, dual core). I see that on ARM architectures the
> get_cycles() function simply returns 0, so, in the time.c of systemtap's
> runtime code I see that a value of 1000 is simply added to the base time. I
> modified this source and made my own __get_cycles() function inside of
> time.c. This function reads the value from a periphery global timer. I'm not
> sure of the resolution of this timer but, this timer is synchronous with the
> global clock (which is max 1GHz) and thus should be a multiple of the actual
> cycle counter. This doesn't seem very accurate however. I am not using the
> actual cycle counter which is available from the performance monitoring unit
> because I am using this for other things, and also it is only a 32 bit
> counter and would overflow too often. Is there any other way to get more
> accurate timing information on an ARM processor?
Our gettimeofday from time.c can be a little flakey even on archs with a
real get_cycles(). The reason we ended up with this is that the
kernel's getnstimeofday can't be used from a context where xtime_lock is
already held. But if you know that your probe points are safe from
that, you could use something like this:
function getnstimeofday:long() %{ /* pure */
struct timespec ts;
getnstimeofday(&ts);
THIS->__retvalue = ts.tv_sec * 1000000000 + ts.tv_nsec;
%}
We don't ship such a function because we can't guarantee its deadlock
safety in the general case. I don't know how good the resolution will
be for ARM, but hopefully its a little better for you.
If all you need is a reasonable time source, e.g. for deltas and not
necessarily the Unix epoch time, then I would recommend just rolling
your own guru function for that periphery timer.
function mytimer:long() %{ /* pure */
THIS->__retvalue = read_my_timer();
%}
Josh