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] |
"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...
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?
Is the get_cycles offset consistent?
Can you force the interrupt to be taken on the same processor as the thread is blocked?
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |