| Message ID | 1480372524-15181-8-git-send-email-john.stultz@linaro.org |
|---|---|
| State | New |
| Headers | show |
On Mon, 28 Nov 2016 14:35:24 -0800 John Stultz <john.stultz@linaro.org> wrote: > From: Joel Fernandes <joelaf@google.com> > > Documentation was missing for mono and mono_raw, add them and also for > the boot clock introduced in this series. > > Cc: Steven Rostedt <rostedt@goodmis.org> Acked-by: Steven Rostedt <rostedt@goodmis.org> -- Steve > Cc: Thomas Gleixner <tglx@linutronix.de> > Cc: Ingo Molnar <mingo@redhat.com> > Cc: Richard Cochran <richardcochran@gmail.com> > Cc: Prarit Bhargava <prarit@redhat.com> > Reviewed-by: Thomas Gleixner <tglx@linutronix.de> > Signed-off-by: Joel Fernandes <joelaf@google.com> > Signed-off-by: John Stultz <john.stultz@linaro.org> > ---
* John Stultz <john.stultz@linaro.org> wrote: > + boot: 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, its 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 on > + ktime_get_boot_fast_ns function for more information. s/its possible/it's possible s/comments on ktime_get_boost_fast_ns function/comments in the ktime_get_boost_fast_ns() function Thanks, Ingo
On Mon, Nov 28, 2016 at 11:26 PM, Ingo Molnar <mingo@kernel.org> wrote: > > * John Stultz <john.stultz@linaro.org> wrote: > >> + boot: 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, its 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 on >> + ktime_get_boot_fast_ns function for more information. > > s/its possible/it's possible > s/comments on ktime_get_boost_fast_ns function/comments in the ktime_get_boost_fast_ns() function > Thanks, I'll fix these up and repost. Regards, Joel > Thanks, > > Ingo
On Tue, 29 Nov 2016, Joel Fernandes wrote: > On Mon, Nov 28, 2016 at 11:26 PM, Ingo Molnar <mingo@kernel.org> wrote: > > > > * John Stultz <john.stultz@linaro.org> wrote: > > > >> + boot: 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, its 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 on > >> + ktime_get_boot_fast_ns function for more information. > > > > s/its possible/it's possible > > s/comments on ktime_get_boost_fast_ns function/comments in the ktime_get_boost_fast_ns() function > > > > Thanks, I'll fix these up and repost. Don't bother. I have fixed it up locally already. Thanks, tglx
diff --git a/Documentation/trace/ftrace.txt b/Documentation/trace/ftrace.txt index 185c39f..5180b09 100644 --- a/Documentation/trace/ftrace.txt +++ b/Documentation/trace/ftrace.txt @@ -362,6 +362,26 @@ of ftrace. Here is a list of some of the key files: to correlate events across hypervisor/guest if tb_offset is known. + mono: This uses the fast monotonic clock (CLOCK_MONOTONIC) + which is monotonic and is subject to NTP rate adjustments. + + mono_raw: + This is the raw monotonic clock (CLOCK_MONOTONIC_RAW) + which is montonic but is not subject to any rate adjustments + and ticks at the same rate as the hardware clocksource. + + boot: 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, its 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 on + ktime_get_boot_fast_ns function for more information. + To set a clock, simply echo the clock name into this file. echo global > trace_clock