Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752420AbbBSR6u (ORCPT ); Thu, 19 Feb 2015 12:58:50 -0500 Received: from foss-mx-na.arm.com ([217.140.108.86]:44167 "EHLO foss-mx-na.foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751597AbbBSR6t (ORCPT ); Thu, 19 Feb 2015 12:58:49 -0500 Message-ID: <1424368719.16038.13.camel@arm.com> Subject: Re: [PATCH 0/2] perf/x86: Add ability to sample TSC From: Pawel Moll To: John Stultz Cc: Adrian Hunter , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , lkml , David Ahern , Frederic Weisbecker , Jiri Olsa , Namhyung Kim , Paul Mackerras , Stephane Eranian , Thomas Gleixner , Steven Rostedt , Andi Kleen , Mathieu Poirier Date: Thu, 19 Feb 2015 17:58:39 +0000 In-Reply-To: References: <1424347870-8492-1-git-send-email-adrian.hunter@intel.com> <54E61FFF.2010201@intel.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.7-0ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2818 Lines: 67 On Thu, 2015-02-19 at 17:50 +0000, John Stultz wrote: > On Thu, Feb 19, 2015 at 9:40 AM, Adrian Hunter wrote: > > On 19/02/2015 7:24 p.m., John Stultz wrote: > >> > >> On Thu, Feb 19, 2015 at 4:11 AM, Adrian Hunter > >> wrote: > >>> > >>> Hi > >>> > >>> With the advent of switching perf_clock to CLOCK_MONOTONIC, > >>> it will not be possible to convert perf_clock directly to/from > >>> TSC. So add the ability to sample TSC instead. > >>> > >>> > >>> Adrian Hunter (2): > >>> perf: Sample additional clock value > >>> perf/x86: Provide TSC for PERF_SAMPLE_CLOCK_ARCH > >> > >> > >> This doesn't seem very portable. The CLOCK_MONOTONIC_RAW clockid was > >> added to provide a arch-neutral abstraction of a free-running hardware > >> counter that isn't affected by adjtimex slewing (though like any > >> counter, it will be affected by non-constant drift). > >> > >> You might consider looking at that if the short term slew adjustments > >> (which result in more accurate timings in the long term) are > >> problematic for you. > > > > > > This is for Intel Processor Trace - which Peter has already > > rightly chastised me for not making plain. > > > > Intel Processor Trace (Intel PT) is a trace that is hardware generated. The > > hardware does not know about linux or its clocks, so the timestamps > > are TSC. I think ARM might have the same issue with ETM or such. i.e. the > > need to synchronize a hardware timestamp with a perf event. > > > > There is a description of Intel PT in the Intel Architecture manuals. > > > > http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html > > Cc'ing Mathieu since he might be familiar w/ any similar issues w/ Coresight. We haven't got to this yet, but it was discussed (briefly) at Plumbers in Dusseldorf. In our case the CS processor trace can be timestamped from yet another clock source, probably hidden behind memory mapped register. Thus the additional time sample of some sort will be required in some form. Peter pointed out that there may be problem with obtaining the "other" timestamps in NMI context, so I was thinking about injecting the synchronisation points as separate records: http://article.gmane.org/gmane.linux.kernel.api/7726/match=perf+sample+additional+clock+value but maybe I'm making it too complicated and what Adrian did, explicitly defining possible timestamps at perf_event_attr level instead of relating them to to posix clock ids is the way to go. No strong opinion here. Pawel -- 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/