HRTIME
Section: High-resolution timing (2)
Updated: Release 0.3
NAME
get_hrtime, get_hrvtime, get_hrutime, get_hrstime, - process timing functions
SYNOPSIS
#include <hrtime.h>
void get_hrtime(volatile struct hrtime_struct *hr, hrtime_t *dest);
void get_hrvtime(volatile struct hrtime_struct *hr, hrtime_t *dest);
void get_hrutime(volatile struct hrtime_struct *hr, hrtime_t *dest);
void get_hrstime(volatile struct hrtime_struct *hr, hrtime_t *dest);
ARGUMENTS
- hr
-
Specifies the structure from which desired timing value should be read.
For performance reasons, hr is not checked for validity. It
is the responsibility of the caller to provide the timer querying
functions with a hrtime_struct returned from get_hrtime_struct.
- dest
-
Specifies the location to which the desired timing value should be written.
Again, it is the responsibility of the caller to insure that dest is
non-null.
DESCRIPTION
- get_hrtime
-
writes the wall time of the process corresponding to hr, in timestamp
counter ticks, to the location specified by dest.
- get_hrvtime
-
writes the total virtual time of the process corresponding to hr, in
timestamp counter ticks, to the location specified by dest.
- get_hrutime
-
writes the virtualized user time of the process corresponding to hr, in
timestamp counter ticks, to the location specified by dest. This
function returns an undefined value if the kernel was not configured with
CONFIG_HRUSTIME, the option enabling additional instrumentation on the
system call path. You can check for this at runtime using
hr->has_ustime.
- get_hrstime
-
writes the virtualized system time of the process corresponding to hr, in
timestamp counter ticks, to the location specified by dest. This
function returns an undefined value if the kernel was not configured with
CONFIG_HRUSTIME, the option enabling additional instrumentation on the
system call path. You can check for this at runtime using
hr->has_ustime.
BUGS
The current implementation is based on the flawed assumption that the
timestamp counter is incremented once per clock cycle (this is true on all
current implementations of Intel processors, but not guaranteed in the
specification).
The current implementation does not calculate the timestamp counter difference
between the CPUs on an SMP box, so timing could be off by an arbitrary
amount. In practice, the timestamp counters on Intel boxes are within a
small number of cycles of each-other, this is by no means guaranteed as there
is also a mechanism to write a value to the timestamp counter.
SEE ALSO
get_hrtime_struct(2),
free_hrtime_struct(2),
times(2),
gettimeofday(2)