On Thu, Feb 19, 2015 at 9:40 AM, Adrian Hunter <adrian.hun...@intel.com> wrote: > On 19/02/2015 7:24 p.m., John Stultz wrote: >> >> On Thu, Feb 19, 2015 at 4:11 AM, Adrian Hunter <adrian.hun...@intel.com> >> 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. thanks -john -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/