Out of order timings of gettimeofday_us()

[Vara Prasad]

Alan D. Brunelle wrote:

> Frank Ch. Eigler wrote:
>
>> "Nathan A. Debardeleben" <ndebard@lanl.gov> writes:
>>
>>  
>>
>>> I have a very simple script which seems to demonstrate time values
>>> coming out of gettimeofday_us() being out of order.  [...]  Is the
>>> us() timing just too fine grained?  If it's acting like this here I
>>> question its values in other places.
>>>     
>>
>>
>> In the absence of another suitable kernel facility, systemtap's
>> timestamping functions use the CPU TSC.  If there is more than one
>> CPU, they have imperfect TSC synchronization, and if a task gets moved
>> between CPUs between the moments you are taking a snapshot, then this
>> sort of thing would be expected.  Does this resemble your scenario?
>>
>> - FChE
>>   
>
> The blktrace kernel component attempts to overcome some of this with 
> periodic synchronization across the CPUs. (see block/blktrace.c for 
> details).
>
> Notwithstanding the effort put into getting that to work, I still find 
> under certain heavy loads time still goes backwards under blktrace. 
> One could use the functionality in blktrace as a starting point, 
> perhaps it would make things better for SystemTAP.
>
> One last thing, I seem to recall there were other issues when doing 
> timings in a multicore CPU environment, but off the top of my head I 
> can not recollect what they were... (old age...)


Hi Jens,

As you can see from this discussion thread looks like block trace has 
similar problem related to keeping track of time. Have you had a chance 
to look into it? If you have some suggestions let us know. If this 
solution works for both block trace and as well as systemtap we could 
move to the combined solution in the mainline.

Thanks,
Vara Prasad

>
> Alan