This is the mail archive of the 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: Out of order timings of gettimeofday_us()

Frank Ch. Eigler wrote:
"Nathan A. Debardeleben" <> 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...)


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