summaryrefslogtreecommitdiff
path: root/gettime.c
AgeCommit message (Collapse)Author
2014-12-17gettime: fix compile warning for !ARCH_HAVE_CPU_CLOCKJens Axboe
Signed-off-by: Jens Axboe <axboe@fb.com>
2014-12-17gettime: offset CPU cycle counter by initial valueJens Axboe
Should then be safe for the full 2^64 cycles, and we push the more expensive variable division to later in the run (which is probably never). Signed-off-by: Jens Axboe <axboe@fb.com>
2014-12-16gettime: cleanup for FIO_DEBUG_TIMEJens Axboe
Signed-off-by: Jens Axboe <axboe@fb.com>
2014-12-16gettime: fix overflow in cycle to usec conversionJens Axboe
If this multiplication overflows: usecs = (t * inv_cycles_per_usec) / 16777216UL; then usecs is 2^64/2^24, which is 1099511627776. Divide that by 10^6 to get seconds, and that is 1099511. Since we cached the old value previously, we'd get stuck with this amount of seconds. To avoid turning this into an expensive division, have a check and only divide if we have to. This avoids the overflow. Signed-off-by: Jens Axboe <axboe@fb.com>
2014-12-16gettime: improve gettimeofday() offload supportJens Axboe
Signed-off-by: Jens Axboe <axboe@fb.com>
2014-12-16gettime: limit warning on CPU clockJens Axboe
Signed-off-by: Jens Axboe <axboe@fb.com>
2014-12-16gettime: don't attempt to fixup what looks like a backwards clockJens Axboe
It could just be a wrap. The code is buggy, kill it, we'll deal with the wrap later. Signed-off-by: Jens Axboe <axboe@fb.com>
2014-11-06Make fio -Wshadow cleanJens Axboe
Found a few issues, actually. Signed-off-by: Jens Axboe <axboe@fb.com>
2014-09-30Constify a few more hot pathsJens Axboe
Signed-off-by: Jens Axboe <axboe@fb.com>
2014-09-24Fix compile for FIO_INC_DEBUG not setJens Axboe
Signed-off-by: Jens Axboe <axboe@fb.com>
2014-04-14gettime: init 'failed' before useJens Axboe
Signed-off-by: Jens Axboe <axboe@fb.com>
2014-04-14gettime: handle pthread_create() failureJens Axboe
Signed-off-by: Jens Axboe <axboe@fb.com>
2014-04-14gettime: use unsigned loop counterJens Axboe
We're comparing with an unsigned exit condition. Signed-off-by: Jens Axboe <axboe@fb.com>
2014-04-08fio: fix s390 time accountingChristian Ehrhardt
The current timer implementation could cause time warps on s390 which ends up as time bound jobs that would never end, because they always reset themself to the old time. When touching this code anyway, we also change it to use the faster stckf and avoid the calibration as we can control the result to be usecs. This also eliminates a few calculations cycle->usec in the hot path for the timer. In case other architectures have similar improved timers that might not be usec based, but nsec based or such a thing any architecture can set ARCH_CPU_CLOCK_CYCLES_PER_USEC to an appropriate per-arch value. This leaves the infrastructure open for others and the compiler will throw our division by 1 away anyway. Signed-off-by: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com> Signed-off-by: Jens Axboe <axboe@fb.com>
2014-04-01Cleanup symbols that should be staticJens Axboe
Run analysis on symbols not used outside of their current file, turn them into statics. Signed-off-by: Jens Axboe <axboe@fb.com>
2014-02-26Branch and cache miss speedupsJens Axboe
Just some low hanging fruit. Signed-off-by: Jens Axboe <axboe@fb.com>
2013-12-06Calloc() cleanupJens Axboe
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2013-04-15Fixup bad logging typesJens Axboe
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2013-04-11Fix a few 4.8 extra anal warningsJens Axboe
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2013-02-26gettime: print 64-bit variable with ULLJens Axboe
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2013-02-25gettime: use 32-bit atomic sequencesJens Axboe
Not all platforms have 64-bit wide atomic sync_and_fetch(). If we just check for overflow, it should be OK to use a 32-bit sequence number. Signed-off-by: Jens Axboe <axboe@kernel.dk>
2013-02-25Fixup wrong types for dprint()Jens Axboe
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2013-02-24gettime: add some sanity checks to platform clockJens Axboe
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2013-02-21Declare 'prev' and 'this' outside the loop to avoid clang warning about ↵Bruce Cran
'prev' being uninitialized Signed-off-by: Jens Axboe <axboe@kernel.dk>
2013-02-03gettime: fixup AMD constant TSC detectionJens Axboe
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2013-02-02clock: hardwire tsc as unreliable on Solaris for nowJens Axboe
Need to double check the cpuid test, it probably only is reliable on Intel. Need to check the CPU vendor and flags appropriately. Signed-off-by: Jens Axboe <axboe@kernel.dk>
2013-01-21gettime: use proper uint64_t types where neededJens Axboe
Windows has 32-bit longs even on 64-bit, so we risk overflowing. Signed-off-by: Jens Axboe <axboe@kernel.dk>
2013-01-18Add info log on whether tsc is reliable or not for --cpuclock-testJens Axboe
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2013-01-10Add configure scriptJens Axboe
Get rid of all the fragile guessing and checking of features, and roll a configure script instead. Signed-off-by: Jens Axboe <axboe@kernel.dk>
2013-01-04time: convert to uint64_tJens Axboe
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2013-01-01gettime: even rounding, don't always round upJens Axboe
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2013-01-01Move 'tsc_reliable' outside of ARCH_HAVE_CPU_CLOCKJens Axboe
Otherwise we fail building on architectures that do not define it, as reported by Dan: cc -o gettime.o -c -std=gnu99 -Wwrite-strings -Wall -O3 -g -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m31 -march=z9-109 -mtune=z10 -DFIO_VERSION='"fio-2.0.12.2"' -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -DFIO_INC_DEBUG gettime.c gettime.c: In function 'fio_clock_init': gettime.c:317:6: error: 'tsc_reliable' undeclared (first use in this function) gettime.c:317:6: note: each undeclared identifier is reported only once for each function it appears in make: *** [gettime.o] Error 1 Reported-by: Dan Horák <dan@danny.cz> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2012-12-21clock: turn expensive division into multiply + cheap divisionJens Axboe
On x86-64, dividing by a variable turns into a hugely expensive divq. It's much cheaper to invert the division. Instead of dividing clocks by clocks-per-usec, multiply by a 16M/clocks-per-usec constant instead. Signed-off-by: Jens Axboe <axboe@kernel.dk>
2012-12-20Use clock_gettime() for CPU clock calibrationJens Axboe
gettimeofday() has very poor resolution on some platforms. So use clock_gettime() instead. Signed-off-by: Jens Axboe <axboe@kernel.dk>
2012-12-18gettime: make last_cycles thread local tooJens Axboe
Avoids a lot of cache line bouncing for threads. Signed-off-by: Jens Axboe <axboe@kernel.dk>
2012-12-18gettime: use pthread_{set,get}specific() for TLSJens Axboe
__thread doesn't work on OSX at least (thanks...), so resort to using the pthread functions to maintaining a per-thread clock check. Signed-off-by: Jens Axboe <axboe@kernel.dk>
2012-12-18gettime: fix race/bug with threads and time keepingJens Axboe
Sam writes: First, the 1 second latency events come in batches and those batches occur suspiciously close to a usec wrap (0.999999 us -> 1.000000 us). Second, if you subtract exactly 1 second from these outlier latencies, the remaining amount is very close to what our instrumented low level driver records for the IO latency and consistent with the expected latencies of our SSD. Similarly, the tv_usec portion of the timeval structs shows increasing values. See snippet below. Format is like start: <start_time.tv_sec>.<start_time.tv_usec> latency: 1004657 us, lba: 1111289192, start: 1355776806.995294 issue: 1355776806.995312 complete: 1355776807.999969 latency: 1000494 us, lba: 203093568, start: 1355776806.999456 issue: 1355776806.999475 complete: 1355776807.999969 latency: 1000404 us, lba: 551350992, start: 1355776806.999546 issue: 1355776806.999565 complete: 1355776807.999969 latency: 1000477 us, lba: 449672928, start: 1355776806.999484 issue: 1355776806.999492 complete: 1355776807.999969 All this pointed to the time collection code being buggy. Reviewing the code, I spotted this in fio_gettime(): /* * If Linux is using the tsc clock on non-synced processors, * sometimes time can appear to drift backwards. Fix that up. */ if (last_tv_valid) { if (tp->tv_sec < last_tv.tv_sec) tp->tv_sec = last_tv.tv_sec; else if (last_tv.tv_sec == tp->tv_sec && tp->tv_usec < last_tv.tv_usec) tp->tv_usec = last_tv.tv_usec; } last_tv_valid = 1; memcpy(&last_tv, tp, sizeof(*tp)); This does not appear to be multi-thread safe. Pre-emption can occur between either comparison and the subsequent update. Commenting it out makes the problem go away (at the expense of being subject to drift). How about making last_tv & last_tv_valid thread-local? Reported-by: Sam Bradshaw <sbradshaw@micron.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2012-12-17gettime: include per-cpu clock calibration in cpu clock testJens Axboe
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2012-12-17gettime: locking fix and debug check for identical sequenceJens Axboe
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2012-12-17cpu clock: add independent test for monotonic/sane TSCJens Axboe
Fire up all threads on the system, checking the clock 100,000 times on each. Then collect and compare results, to ensure we never have a clock that goes backwards. Signed-off-by: Jens Axboe <axboe@kernel.dk>
2012-12-14clock: ensure that we re-init if the clocksource changes from the defaultJens Axboe
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2012-12-10cpu clock: round up when dividing by samplesJens Axboe
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2012-12-10gettime: fix CPU calibration reported meanJens Axboe
Bug introduced in fa80feae. It only affected the reported mean if --debug=time was used, cosmetic issue. Signed-off-by: Jens Axboe <axboe@kernel.dk>
2012-12-10gettime: calibration rounding errorJens Axboe
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2012-12-10Increase CPU clock calibration accuracyJens Axboe
Lets throw some more loops at it, it reduces the noise. Signed-off-by: Jens Axboe <axboe@kernel.dk>
2012-12-09Add check for invariant TSC on x86 and use TSC is default clock if reliableJens Axboe
TSC is by far the fastest clock we can use. Check the CPUID bits for whether it is both constant rate AND synced across cores. If it is, we can use it as our default clock source. Fio will default to this clock source on x86 if no other clock source is specifically given with clocksource= in the job file. Signed-off-by: Jens Axboe <axboe@kernel.dk>
2012-11-06Move code around to satisfy t/stest linkageJens Axboe
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2012-08-02mutex: make 0/1 FIO_MUTEX_LOCKED and FIO_MUTEX_UNLOCKEDJens Axboe
Makes the API look cleaner. Signed-off-by: Jens Axboe <axboe@kernel.dk>
2012-02-20Add FIO_PREFERRED_CLOCK_SOURCE to allow selection of clock source on a ↵Bruce Cran
per-platform basis. Signed-off-by: Jens Axboe <axboe@kernel.dk>
2012-02-09Add gettime.hJens Axboe
time.h is a mix of gettime.c and time.c Signed-off-by: Jens Axboe <axboe@kernel.dk>