From: Peter Zijlstra <peterz@infradead.org>
To: John Stultz <john.stultz@linaro.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Stephane Eranian <eranian@google.com>,
Pawel Moll <pawel.moll@arm.com>,
LKML <linux-kernel@vger.kernel.org>,
"mingo@elte.hu" <mingo@elte.hu>,
Paul Mackerras <paulus@samba.org>,
Anton Blanchard <anton@samba.org>,
Will Deacon <Will.Deacon@arm.com>,
"ak@linux.intel.com" <ak@linux.intel.com>,
Pekka Enberg <penberg@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>,
Robert Richter <robert.richter@amd.com>
Subject: Re: [RFC] perf: need to expose sched_clock to correlate user samples with kernel samples
Date: Wed, 20 Feb 2013 11:29:20 +0100 [thread overview]
Message-ID: <1361356160.10155.22.camel@laptop> (raw)
In-Reply-To: <5123C3AF.8060100@linaro.org>
On Tue, 2013-02-19 at 10:25 -0800, John Stultz wrote:
> So describe how the perf time domain is different then
> CLOCK_MONOTONIC_RAW.
The primary difference is that the trace/sched/perf time domain is not
strictly monotonic, it is only locally monotonic -- that is two time
stamps taken on the same cpu are guaranteed to be monotonic.
Furthermore, to make it useful, there's an actual bound on the inter-cpu
drift (implemented by limiting the drift to CLOCK_MONOTONIC).
Additionally -- to increase use -- we also added a monotonic sync point
when cpu A queries time of cpu B.
> My concern here is that we're basically creating a kernel interface
> that
> exports implementation-defined semantics (again: whatever perf does
> right now). And I think folks want to do this, because adding
> CLOCK_PERF
> is easier then trying to:
>
> 1) Get a lock-free method for accessing CLOCK_MONOTONIC_RAW
>
> 2) Having perf interpolate its timestamps to CLOCK_MONOTONIC, or
> CLOCKMONOTONIC_RAW when it exports the data
Mostly cheaper, not easier. Given unstable TSC, MONOTONIC will have to
fall back to another clock source (hpet, acpi_pm and other assorted
crap).
In order to avoid this, we'd had to relax the requirements. Using
anything other than TSC is simply not an option.
next prev parent reply other threads:[~2013-02-20 10:29 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-16 10:13 [RFC] perf: need to expose sched_clock to correlate user samples with kernel samples Stephane Eranian
2012-10-16 17:23 ` Peter Zijlstra
2012-10-18 19:33 ` Stephane Eranian
2012-11-10 2:04 ` John Stultz
2012-11-11 20:32 ` Stephane Eranian
2012-11-12 18:53 ` John Stultz
2012-11-12 20:54 ` Stephane Eranian
2012-11-12 22:39 ` John Stultz
2012-11-13 20:58 ` Steven Rostedt
2012-11-14 22:26 ` John Stultz
2012-11-14 23:30 ` Steven Rostedt
2013-02-01 14:18 ` Pawel Moll
2013-02-05 21:18 ` David Ahern
2013-02-05 22:13 ` Stephane Eranian
2013-02-05 22:28 ` John Stultz
2013-02-06 1:19 ` Steven Rostedt
2013-02-06 18:17 ` Pawel Moll
2013-02-13 20:00 ` Stephane Eranian
2013-02-14 10:33 ` Pawel Moll
2013-02-18 15:16 ` Stephane Eranian
2013-02-18 18:59 ` David Ahern
2013-02-18 20:35 ` Thomas Gleixner
2013-02-19 18:25 ` John Stultz
2013-02-19 19:55 ` Thomas Gleixner
2013-02-19 20:15 ` Thomas Gleixner
2013-02-19 20:35 ` John Stultz
2013-02-19 21:50 ` Thomas Gleixner
2013-02-19 22:20 ` John Stultz
2013-02-20 10:06 ` Thomas Gleixner
2013-02-20 10:29 ` Peter Zijlstra [this message]
2013-02-23 6:04 ` John Stultz
2013-02-25 14:10 ` Peter Zijlstra
2013-03-14 15:34 ` Stephane Eranian
2013-03-14 19:57 ` Pawel Moll
2013-03-31 16:23 ` David Ahern
2013-04-01 18:29 ` John Stultz
2013-04-01 22:29 ` David Ahern
2013-04-01 23:12 ` John Stultz
2013-04-03 9:17 ` Stephane Eranian
2013-04-03 13:55 ` David Ahern
2013-04-03 14:00 ` Stephane Eranian
2013-04-03 14:14 ` David Ahern
2013-04-03 14:22 ` Stephane Eranian
2013-04-03 17:57 ` John Stultz
2013-04-04 8:12 ` Stephane Eranian
2013-04-04 22:26 ` John Stultz
2013-04-02 7:54 ` Peter Zijlstra
2013-04-02 16:05 ` Pawel Moll
2013-04-02 16:19 ` John Stultz
2013-04-02 16:34 ` Pawel Moll
2013-04-03 17:19 ` Pawel Moll
2013-04-03 17:29 ` John Stultz
2013-04-03 17:35 ` Pawel Moll
2013-04-03 17:50 ` John Stultz
2013-04-04 7:37 ` Richard Cochran
2013-04-04 16:33 ` Pawel Moll
2013-04-04 16:29 ` Pawel Moll
2013-04-05 18:16 ` Pawel Moll
2013-04-06 11:05 ` Richard Cochran
2013-04-08 17:58 ` Pawel Moll
2013-04-08 19:05 ` John Stultz
2013-04-09 5:02 ` Richard Cochran
2013-02-06 18:17 ` Pawel Moll
2013-06-26 16:49 ` David Ahern
2013-07-15 10:44 ` Pawel Moll
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=1361356160.10155.22.camel@laptop \
--to=peterz@infradead.org \
--cc=Will.Deacon@arm.com \
--cc=ak@linux.intel.com \
--cc=anton@samba.org \
--cc=eranian@google.com \
--cc=john.stultz@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=paulus@samba.org \
--cc=pawel.moll@arm.com \
--cc=penberg@gmail.com \
--cc=robert.richter@amd.com \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.