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