Re: [PATCH 0/2] perf/x86: Add ability to sample TSC

[Pawel Moll <pawel.moll@arm.com>]

On Thu, 2015-02-19 at 17:50 +0000, John Stultz wrote:
> On Thu, Feb 19, 2015 at 9:40 AM, Adrian Hunter <adrian.hunter@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.hunter@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.

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