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: Problems with gettimeofday_ns()


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.


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