Problems with gettimeofday_ns()

[Julio M. Merino Vidal]

On Feb 25, 2008, at 16:10 , Frank Ch. Eigler wrote:

> "Julio M. Merino Vidal" <jmerino@ac.upc.edu> writes:
>
>> [...]  So, in this case, is it still possible for SystemTap to
>> receive events from different [Cell virtual] CPUs in an incorrect
>> order?  [...]
>
> It is unlikely.  The only centralized part in systemtap that could
> receive events out of order is the user-space "stapio" process, and
> depending on whether "bulk mode" (stap -b) is on, the kernel-side
> trace data buffer.  Events occurring in the kernel are not queued but
> handled immediately.  It is conceivable that there is a serialization
> bug somewhere in the buffering code...

I've also noticed some random corruption bugs in the traces, so this  
might be a possibility.

>> 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.
>> [...]
>
> Is it possible that this analysis is mistaken?  Maybe the wakeup
> occurred to to a prior interrupt, and just happens to be "nearby" the
> current one?

I don't think so.  Once a stop interrupt has happened for a given SPU  
context, it cannot happen again for that context until its service  
thread is woken up and it has reprogrammed the execution of the  
context.  Sure, you'd receive another interrupt "nearby", but that'd  
be tied to another context so it'd not trigger the problem I'm seeing.

>   Is the get_cycles offset consistent?

I don't know, but I could check.  This doesn't happen consistently,  
though, so I'd assume that it's not.

>   Can you force the
> interrupt to be taken on the same processor as the thread is blocked?

Again, I don't think so, but I really have no idea.

Thanks.