24 Jul, 2014
14 commits
-
Tracers want a correlated time between the kernel instrumentation and
user space. We really do not want to export sched_clock() to user
space, so we need to provide something sensible for this.Using separate data structures with an non blocking sequence count
based update mechanism allows us to do that. The data structure
required for the readout has a sequence counter and two copies of the
timekeeping data.On the update side:
smp_wmb();
tkf->seq++;
smp_wmb();
update(tkf->base[0], tk);
smp_wmb();
tkf->seq++;
smp_wmb();
update(tkf->base[1], tk);On the reader side:
do {
seq = tkf->seq;
smp_rmb();
idx = seq & 0x01;
now = now(tkf->base[idx]);
smp_rmb();
} while (seq != tkf->seq)So if a NMI hits the update of base[0] it will use base[1] which is
still consistent, but this timestamp is not guaranteed to be monotonic
across an update.The timestamp is calculated by:
now = base_mono + clock_delta * slope
So if the update lowers the slope, readers who are forced to the
not yet updated second array are still using the old steeper slope.tmono
^
| o n
| o n
| u
| o
|o
|12345678---> reader ordero = old slope
u = update
n = new slopeSo reader 6 will observe time going backwards versus reader 5.
While other CPUs are likely to be able observe that, the only way
for a CPU local observation is when an NMI hits in the middle of
the update. Timestamps taken from that NMI context might be ahead
of the following timestamps. Callers need to be aware of that and
deal with it.V2: Got rid of clock monotonic raw and reorganized the data
structures. Folded in the barrier fix from Mathieu.Signed-off-by: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Steven Rostedt
Cc: Mathieu Desnoyers
Signed-off-by: John Stultz -
Provide a ktime_t based interface for raw monotonic time.
Signed-off-by: Thomas Gleixner
Signed-off-by: John Stultz -
timekeeping_clocktai() is not used in fast pathes, so the extra
timespec conversion is not problematic.Signed-off-by: Thomas Gleixner
Signed-off-by: John Stultz -
get_monotonic_boottime() is not used in fast pathes, so the extra
timespec conversion is not problematic.Signed-off-by: Thomas Gleixner
Signed-off-by: John Stultz -
No more users.
Signed-off-by: Thomas Gleixner
Signed-off-by: John Stultz -
A lot of code converts either timespecs or ktime_t to
nanoseconds. Provide helper functions.Signed-off-by: Thomas Gleixner
Signed-off-by: John Stultz -
No more users.
Signed-off-by: Thomas Gleixner
Signed-off-by: John Stultz -
ktime based conversion function to map a monotonic time stamp to a
different CLOCK.Signed-off-by: Thomas Gleixner
Signed-off-by: John Stultz -
Signed-off-by: Thomas Gleixner
Signed-off-by: John Stultz -
Signed-off-by: Thomas Gleixner
Signed-off-by: John Stultz -
Speed up the readout.
Signed-off-by: Thomas Gleixner
Signed-off-by: John Stultz -
Provide a helper function which lets us implement ktime_t based
interfaces for real, boot and tai clocks.Signed-off-by: Thomas Gleixner
Signed-off-by: John Stultz -
To convert callers of the core code to timespec64 we need to provide
the proper interfaces.Signed-off-by: Thomas Gleixner
Signed-off-by: John Stultz -
Right now we have time related prototypes in 3 different header
files. Move it to a single timekeeping header file and move the core
internal stuff into a core private header.Signed-off-by: Thomas Gleixner
Signed-off-by: John Stultz
