From mboxrd@z Thu Jan  1 00:00:00 1970
From: alexandre.montplaisir@polymtl.ca (Alexandre Montplaisir)
Date: Tue, 30 Nov 2010 18:18:14 -0500
Subject: [ltt-dev] Libtraceread sequential reading of events with	the
 same timstamp
In-Reply-To: <20101130203016.GB28686@Krystal>
References: <4CF55ACF.7060107@ericsson.com> <20101130203016.GB28686@Krystal>
Message-ID: <4CF58636.7000708@polymtl.ca>

On 10-11-30 03:30 PM, Mathieu Desnoyers wrote:
> * Matthew Khouzam (matthew.khouzam at ericsson.com) wrote:
>> Hello world,
>> When you have different events in different tracefiles of the same trace
>> that have the same timestamp, is the order of reading supposed to be
>> pre-determined?
>>
>> An example to better illustrate my question.
>>
>> If at 100ns you have a kernel softIrqEntry and a fs open that occur.
>> Would you have a prefered order of reading the trace, and could this
>> affect the state machine.
> If two events happen in different trace files at exactly the same time,
> there is nothing we can tell about the ordering. So their relative order
> is not important, even though it could affect the state machine in rare
> cases.

Do you have any examples of such cases?

The way I see it, if we have events from different files with the same 
timestamp, they would most probably be unrelated. If we do get 
"conflicting" information (a file open and a file close on the same 
file, by the same process, at the same time), this would probably be a 
problem with the kernel or more likely the tracing mechanism.


Alexandre


> Ideally, the state machine should become clever enough to detect
> these cases where relative ordering of events is unknown based on
> timestamps delta being under a certain threshold, or based on other
> instrumentat (interrupt execution surrounding the event). I'm not saying
> that LTTV and TMF are doing a particularly good at this at the moment --
> it should be considered as something to improve.
>
> Thanks,
>
> Mathieu
>