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)