Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752324AbbEDUsE (ORCPT ); Mon, 4 May 2015 16:48:04 -0400 Received: from mail-ie0-f177.google.com ([209.85.223.177]:34345 "EHLO mail-ie0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751642AbbEDUr6 (ORCPT ); Mon, 4 May 2015 16:47:58 -0400 MIME-Version: 1.0 In-Reply-To: <20150504200515.GA24626@dreric01-Precision-T1650> References: <1430750469-16428-1-git-send-email-drew.richardson@arm.com> <199091314.42407.1430752205090.JavaMail.zimbra@efficios.com> <20150504200515.GA24626@dreric01-Precision-T1650> Date: Mon, 4 May 2015 13:47:57 -0700 Message-ID: Subject: Re: [PATCH] ftrace: Provide trace clock monotonic raw From: John Stultz To: Drew Richardson Cc: Mathieu Desnoyers , Steven Rostedt , Ingo Molnar , "linux-kernel@vger.kernel.org" , Thomas Gleixner , Peter Zijlstra , Wade Cherry , Pawel Moll Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2173 Lines: 52 On Mon, May 4, 2015 at 1:05 PM, Drew Richardson 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 >> > >> >> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/