Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751837AbbBMHJd (ORCPT ); Fri, 13 Feb 2015 02:09:33 -0500 Received: from mga11.intel.com ([192.55.52.93]:27335 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751535AbbBMHJc (ORCPT ); Fri, 13 Feb 2015 02:09:32 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,569,1418112000"; d="scan'208";a="685179256" Message-ID: <54DDA2B8.6040208@intel.com> Date: Fri, 13 Feb 2015 09:07:36 +0200 From: Adrian Hunter Organization: Intel Finland Oy, Registered Address: PL 281, 00181 Helsinki, Business Identity Code: 0357606 - 4, Domiciled in Helsinki User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Peter Zijlstra CC: Pawel Moll , ajh mls , Richard Cochran , Steven Rostedt , Ingo Molnar , Paul Mackerras , Arnaldo Carvalho de Melo , John Stultz , Masami Hiramatsu , Christopher Covington , Namhyung Kim , David Ahern , Thomas Gleixner , Tomeu Vizoso , "linux-kernel@vger.kernel.org" , "linux-api@vger.kernel.org" Subject: Re: [PATCH v5] perf: Use monotonic clock as a source for timestamps References: <1415292718-19785-2-git-send-email-pawel.moll@arm.com> <1421872037-12559-1-git-send-email-pawel.moll@arm.com> <1422895966.4944.25.camel@arm.com> <1422955245.4944.26.camel@arm.com> <20150211161256.GH2896@worktop.programming.kicks-ass.net> <54DC7AC6.5010605@intel.com> <20150212102814.GK2896@worktop.programming.kicks-ass.net> In-Reply-To: <20150212102814.GK2896@worktop.programming.kicks-ass.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1715 Lines: 44 On 12/02/15 12:28, Peter Zijlstra wrote: > On Thu, Feb 12, 2015 at 12:04:54PM +0200, Adrian Hunter wrote: >> On 11/02/15 18:12, Peter Zijlstra wrote: >>> >>> How about something like the below? I _think_ it should mostly work for >>> x86, where the tsc is a 64bit wide cycle counter. >> >> It would have to be based on CLOCK_MONOTONIC_RAW not CLOCK_MONOTONIC > > Why? In the CLOCK_MONOTONIC case, the components of the calculation (mult and shift etc) are subject to change, so the calculation would be increasingly inaccurate the greater the time between reading those values the reading TSC or capturing perf events. Accuracy is important for matching sideband events against Intel PT. e.g. did a mmap event happen before or after a given TSC timestamp. Adding another sample value (Pawel's patch 3) is more accurate and simpler to understand. It just needs to be extended to allow TSC. > >> and you would have to check the clocksource is TSC. > > It implicitly does that; it has that sched_clock_stable() thing, but > yeah I suppose someone could change the clocksource even though the tsc > is stable. > > Not using TSC when its available is quite crazy though.. but sure. > >> Why is CLOCK_MONOTONIC preferred anyway - I would have thought any >> adjustment would skew performance timings? > > Because you can do inter-machine stuff with MONOTONIC and that's > entirely impossible with MONO_RAW. Ok, the man page does not make it sound as bad as that. -- 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/