summaryrefslogtreecommitdiff
path: root/Documentation
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2018-04-29 19:03:25 +0300
committerLinus Torvalds <torvalds@linux-foundation.org>2018-04-29 19:03:25 +0300
commit810fb07a9b504ac22b95899cf8b39d25a5f3e5c5 (patch)
tree9dc8cf4ef4b9795b82c4b5204f80475da482ccc5 /Documentation
parent7d9e55feae5543b16ec9d433079c9db455929a67 (diff)
parenta3ed0e4393d6885b4af7ce84b437dc696490a530 (diff)
downloadlinux-810fb07a9b504ac22b95899cf8b39d25a5f3e5c5.tar.xz
Merge branch 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull timer fixes from Thomas Gleixner: "Two fixes from the timer departement: - Fix a long standing issue in the NOHZ tick code which causes RB tree corruption, delayed timers and other malfunctions. The cause for this is code which modifies the expiry time of an enqueued hrtimer. - Revert the CLOCK_MONOTONIC/CLOCK_BOOTTIME unification due to regression reports. Seems userspace _is_ relying on the documented behaviour despite our hope that it wont" * 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: Revert: Unify CLOCK_MONOTONIC and CLOCK_BOOTTIME tick/sched: Do not mess with an enqueued hrtimer
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/trace/ftrace.rst14
1 files changed, 11 insertions, 3 deletions
diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst
index e45f0786f3f9..67d9c38e95eb 100644
--- a/Documentation/trace/ftrace.rst
+++ b/Documentation/trace/ftrace.rst
@@ -461,9 +461,17 @@ of ftrace. Here is a list of some of the key files:
and ticks at the same rate as the hardware clocksource.
boot:
- Same as mono. Used to be a separate clock which accounted
- for the time spent in suspend while CLOCK_MONOTONIC did
- not.
+ This is the boot clock (CLOCK_BOOTTIME) and is based on the
+ fast monotonic clock, but also accounts for time spent in
+ suspend. Since the clock access is designed for use in
+ tracing in the suspend path, some side effects are possible
+ if clock is accessed after the suspend time is accounted before
+ the fast mono clock is updated. In this case, the clock update
+ appears to happen slightly sooner than it normally would have.
+ Also on 32-bit systems, it's possible that the 64-bit boot offset
+ sees a partial update. These effects are rare and post
+ processing should be able to handle them. See comments in the
+ ktime_get_boot_fast_ns() function for more information.
To set a clock, simply echo the clock name into this file::