This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: accurate gettimeofday_ns() on arm cortex a9 mpcore


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]