Problems with gettimeofday_ns()

Julio M. Merino Vidal jmerino@ac.upc.edu
Mon Feb 25 11:20:00 GMT 2008


On Feb 22, 2008, at 18:14 , Masami Hiramatsu wrote:

> Julio M. Merino Vidal wrote:
>> Now I am finding another issue slightly related to this.  I have just
>> added a new marker to the code in an interrupt context, and this
>> interrupt wakes up a specific thread to handle it later on.  The
>> problem is that, if the interrupt is handled on one CPU and the
>> thread, once awaken, is handled by the other one, I can still get the
>> timestamps (cycles) reversed.  Any easy way around this?
>
> Unfortunately, there is no general workaround for this issue, because
> it strongly depends on the processor specification.
> For example, IPF could easily synchronize time because it has a
> system-wide clock source. However, most of i386 variant processors
> don't have this kind of clock source. Moreover, some of it may
> change clock frequency when it changes its cpu-frequency.
>
> If all of your processors have constant-freq clock and same
> frequency, there are constant gaps between each processor's clock.
> So, I think easy way is to estimate the gap from log by hand...

I'm finding this issue in a Cell processor (PPC64, 2-way SMT) and, as  
far as I know, its time base register is shared among all virtual  
processors (and some small experiments running K.Prasad's module seem  
to confirm this).

So, in this case, is it still possible for SystemTap to receive  
events from different CPUs in an incorrect order?  The thing is I had  
not noticed this problem until I added a probe inside interrupt  
context.  In all other cases, the resulting traces are sorted  
correctly when using get_cycles().

What I have done in more detail is: add a marker in the interrupt  
code that gets called when an SPU stops execution, and another marker  
in the thread that is sleeping waiting for that condition.  The  
interrupt code just wakes up the other thread.  If the thread is  
woken up in CPU 1 and the interrupt is handled in CPU 0, I notice the  
time inversion problem I mentioned.



More information about the Systemtap mailing list