Re: [PATCH] ftrace: Provide trace clock monotonic raw

[Drew Richardson <drew.richardson@arm.com>]

On Mon, May 04, 2015 at 09:57:48PM +0100, Peter Zijlstra wrote:
> On Mon, May 04, 2015 at 01:05:19PM -0700, Drew Richardson wrote:
> > 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. 
> 
> Which should not matter at all, right? If both sources are using the
> same clock (they are) then its trivial to merge them and everything
> works as expected.
> 
> > But I'd prefer to use a clock that is advancing at a consistent
> > rate, hence CLOCK_MONOTONIC_RAW.
> 
> Right, Mathieu is asking _why_ you prefer that?
> 

I think John described it well.

On Mon, May 04, 2015 at 09:47:57PM +0100, John Stultz wrote:
> ... [D]uring 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.
>

CLOCK_MONOTONIC_RAW will advance more constantly than CLOCK_MONOTONIC.

Imagine someone is trying to optimize a particular program to reduce
instructions executed for a given workload while minimizing the effect
on runtime. Also suppose that ntp is running and potentially making
larger adjustments to CLOCK_MONOTONIC. If ntp is adjusting
CLOCK_MONOTONIC to advance more rapidly, the program will appear to
use fewer instructions per second but run longer than it would if
CLOCK_MONOTONIC_RAW had been used. The total number of instructions
observed would be the same regardless of the clock source used, but
how it's attributed to time would be affected.

Conversely if ntp is adjusting CLOCK_MONOTONIC to advance more slowly,
the program will appear to use more instructions per second but run
more quickly. Of course there are many sources that can cause jitter
in performance measurements on modern processors, but I'd like to
remove ntp from the list.

Thanks,

Drew