Skip to content

timekeeping: Unify clock MONOTONIC and clock BOOTTIME

Thomas Gleixner linux-input linux-pm lkml 1 version In review

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 Latest7 patches 25 repliesIn review

Patches in v1 No applies recorded yet

#Subject and filesSizeRepliesApplied
1/7timekeeping: Provide CLOCK_MONOTONIC_ACTIVEinclude/linux/timekeeper_internal.h include/linux/timekeeping.h include/uapi/linux/time.h +3 more+55 -00 replies
2/7timekeeping: Make clock MONOTONIC behave like clock BOOTTIMEkernel/time/tick-common.c kernel/time/tick-internal.h kernel/time/tick-sched.c +1 more+34 -30 replies
3/7Input: evdev - Conflate clock MONOTONIC and BOOTTIMEdrivers/input/evdev.c+1 -60 replies
4/7timekeeping: Remove boot time specific codeinclude/linux/timekeeping.h kernel/time/timekeeping.c+17 -560 replies
5/7posix-timers: Conflate clock MONOTONIC and BOOTTIMEkernel/time/posix-timers.c+1 -220 replies
6/7hrtimer: Conflate clock MONOTONIC and BOOTTIMEinclude/linux/hrtimer.h kernel/time/hrtimer.c kernel/time/timekeeping.c +1 more+3 -200 replies
7/7tracing: Conflate boot and monotonic clockDocumentation/trace/ftrace.txt include/linux/timekeeping.h kernel/trace/trace.c+4 -180 replies

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

Cover letter [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

While working through the melted spectrum induced backlog I found that last years discussion about unifying clock MONOTONIC and clock BOOTTIME has died out and obviously nobody had time to do testing on that half baken RFC patch:

https://lkml.kernel.org/r/alpine.DEB.2.20.1711180123360.2186@nanos

So I sat down and revisited it a bit more carefully than last time. The following series is the result of this work. The main differences are:

1) Provide CLOCK_MONOTONIC_ACTIVE which has the current CLOCK_MONOTONIC behaviour, i.e. it's monotonic time since boot minus the time spent in suspend.

The reason why I introduced it is that currently it's possible for user space to determine the time spent in suspend by subtracting clock monotonic and clock boot time time stamps. When CLOCK_MONOTONIC behaves like CLOCK_BOOTTIME then this is not longer possible.

As a side effect when CLOCK_MONOTONIC_ACTIVE is supported by a kernel then this is also an indicator that CLOCK_MONOTONIC and CLOCK_BOOTTIME are identical. So it's possible to determine this w/o playing games with kernel versions etc. Older kernels simply return -EiNVAL if CLOCK_MONOTONIC_ACTIVE is requested in clock_gettime().

2) Fixed a few places which I missed last time, which means also that my warning in the original changelog was justified.

3) Consolidated the core users to get rid of the seperate implementations for the two clocks

Note, there are user space visible side effects. The difference between CLOCK_MONOTONIC and CLOCK_BOOTTIME is well documented and it's unclear whether applications rely on it or not.

This really needs lot of testing, documentation updates and more input from userspace folks to make a final decision.

Thanks,

tglx

---

 Documentation/trace/ftrace.txt      |   14 +-----
 drivers/input/evdev.c               |    7 ---
 include/linux/hrtimer.h             |    2 
 include/linux/timekeeper_internal.h |    2 
 include/linux/timekeeping.h         |   37 +++++------------
 include/uapi/linux/time.h           |    1 
 kernel/time/hrtimer.c               |   16 -------
 kernel/time/posix-stubs.c           |    2 
 kernel/time/posix-timers.c          |   26 ++++--------
 kernel/time/tick-common.c           |   15 ++++++
 kernel/time/tick-internal.h         |    6 ++
 kernel/time/tick-sched.c            |    9 ++++
 kernel/time/timekeeping.c           |   78 ++++++++++++++++++------------------
 kernel/time/timekeeping.h           |    1 
 kernel/trace/trace.c                |    2 
 15 files changed, 104 insertions(+), 114 deletions(-)