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

From: John Stultz
Date: Mon May 04 2015 - 16:48:06 EST


On Mon, May 4, 2015 at 1:05 PM, Drew Richardson <drew.richardson@xxxxxxx> 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.richardson@xxxxxxx>
>> >
>>
>> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/