On Mon, May 4, 2015 at 1:05 PM, Drew Richardson <drew.richard...@arm.com> wrote: > On Mon, May 04, 2015 at 04:10:05PM +0100, Mathieu Desnoyers wrote: >> ----- Original Message ----- >> > Expose the NMI safe accessor to the monotonic raw clock to the >> > tracer. The mono clock was added with commit >> > 1b3e5c0936046e7e023149ddc8946d21c2ea20eb. Although the monotonic raw >> > clock cannot be used to compare time between different machines, it is >> > not perterbed by ntp. >> >> perterbed -> perturbed > > Oops, I'll correct that in the next version. > >> > >> > Signed-off-by: Drew Richardson <drew.richard...@arm.com> >> > >> >> What is the use-case that justify exposing the "raw fast" >> clock that cannot be handled by the "monotonic fast" clock ? >> >> Thanks, >> >> Mathieu > > I'm collecting and merging data from perf, with Android Atrace data > (writes to /sys/kernel/debug/tracing/trace_marker) which ends up in > the ftrace stream and other measurements collected from > userspace. Currently the only clock readable from userspace, supported > by perf and by ftrace is CLOCK_MONOTONIC. However this clock is > affected by the incremental adjustments performed by adjtime(3) and > NTP. But I'd prefer to use a clock that is advancing at a consistent > rate, hence CLOCK_MONOTONIC_RAW.
Well, I'd caution against assuming CLOCK_MONOTONIC_RAW is really a consistent rate, since w/ thermal changes the oscillator likely will drift around. But especially during early initialization, ntp can manipulate the CLOCK_MONOTONIC freq more drastically to align time. Another more concrete benefit is that since CLOCK_MONOTONIC is frequency adjusted, its possible for slight inconsistencies to appear when using the lock-free ktime_get_mono_fast_ns() accessor that perf uses. With CLOCK_MONOTONIC_RAW, since there are no frequency adjustments made, inconsistencies shouldn't occur with the lock-free accessor. thanks -john -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
