From: Adrian Hunter <adrian.hunter@intel.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Pawel Moll <pawel.moll@arm.com>, ajh mls <ajhmls@gmail.com>,
Richard Cochran <richardcochran@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ingo Molnar <mingo@redhat.com>, Paul Mackerras <paulus@samba.org>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
John Stultz <john.stultz@linaro.org>,
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
Christopher Covington <cov@codeaurora.org>,
Namhyung Kim <namhyung@kernel.org>,
David Ahern <dsahern@gmail.com>,
Thomas Gleixner <tglx@linutronix.de>,
Tomeu Vizoso <tomeu@tomeuvizoso.net>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>
Subject: Re: [PATCH v5] perf: Use monotonic clock as a source for timestamps
Date: Fri, 13 Feb 2015 09:07:36 +0200 [thread overview]
Message-ID: <54DDA2B8.6040208@intel.com> (raw)
In-Reply-To: <20150212102814.GK2896@worktop.programming.kicks-ass.net>
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.
next prev parent reply other threads:[~2015-02-13 7:09 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-06 16:51 [PATCH v4 0/3] perf: User/kernel time correlation and event generation Pawel Moll
2014-11-06 16:51 ` [PATCH v4 1/3] perf: Use monotonic clock as a source for timestamps Pawel Moll
2014-11-27 15:05 ` Pawel Moll
2014-12-11 13:39 ` Pawel Moll
2015-01-05 13:01 ` Peter Zijlstra
2015-01-21 15:47 ` Pawel Moll
2015-01-05 13:00 ` Peter Zijlstra
2015-01-21 15:52 ` Pawel Moll
2015-01-21 19:48 ` Pawel Moll
2015-01-21 20:07 ` Pawel Moll
2015-01-16 12:41 ` Adrian Hunter
2015-01-21 20:27 ` [PATCH v5] " Pawel Moll
2015-02-02 16:52 ` Pawel Moll
[not found] ` <CAN+dfcT_6zZZ4oeyngUE5N0Wtx2B9CvXsfU71m+cuyXpq2KBdw@mail.gmail.com>
2015-02-03 9:20 ` Pawel Moll
2015-02-11 16:12 ` Peter Zijlstra
2015-02-12 10:04 ` Adrian Hunter
2015-02-12 10:28 ` Peter Zijlstra
2015-02-12 15:38 ` Peter Zijlstra
2015-02-13 0:25 ` John Stultz
2015-02-13 7:07 ` Adrian Hunter [this message]
2014-11-06 16:51 ` [PATCH v4 2/3] perf: Userspace event Pawel Moll
2015-01-05 13:12 ` Peter Zijlstra
2015-01-21 16:01 ` Pawel Moll
2014-11-06 16:51 ` [PATCH v4 3/3] perf: Sample additional clock value Pawel Moll
2015-01-05 13:45 ` Peter Zijlstra
2015-01-05 19:17 ` John Stultz
2015-01-21 17:12 ` Pawel Moll
2015-01-21 17:44 ` John Stultz
2015-01-21 17:54 ` Pawel Moll
2015-01-21 18:05 ` John Stultz
2015-01-23 17:06 ` Pawel Moll
2015-01-23 18:05 ` David Ahern
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54DDA2B8.6040208@intel.com \
--to=adrian.hunter@intel.com \
--cc=acme@kernel.org \
--cc=ajhmls@gmail.com \
--cc=cov@codeaurora.org \
--cc=dsahern@gmail.com \
--cc=john.stultz@linaro.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=paulus@samba.org \
--cc=pawel.moll@arm.com \
--cc=peterz@infradead.org \
--cc=richardcochran@gmail.com \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=tomeu@tomeuvizoso.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).