linux-kernel - Re: [PATCH] ftrace: Provide trace clock monotonic raw

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 4 May 2015 13:47:57 -0700
From:	John Stultz <john.stultz@...aro.org>
To:	Drew Richardson <drew.richardson@....com>
Cc:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Ingo Molnar <mingo@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Wade Cherry <Wade.Cherry@....com>,
	Pawel Moll <pawel.moll@....com>
Subject: Re: [PATCH] ftrace: Provide trace clock monotonic raw

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