From: David Ahern <dsahern@gmail.com>
To: Pawel Moll <pawel.moll@arm.com>,
Stephane Eranian <eranian@google.com>,
Peter Zijlstra <peterz@infradead.org>,
John Stultz <john.stultz@linaro.org>,
Thomas Gleixner <tglx@linutronix.de>
Cc: 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: Sun, 31 Mar 2013 10:23:49 -0600 [thread overview]
Message-ID: <51586315.7080006@gmail.com> (raw)
In-Reply-To: <1363291021.3100.144.camel@hornet>
On 3/14/13 1:57 PM, Pawel Moll wrote:
> Ok, how about the code below? I must say I have some doubts about the
> resolution, as there seem to be no generic way of figuring it out for
> the sched_clock (the arch/arm/kernel/sched_clock.c is actually
> calculating it, but than just prints it out and nothing more).
>
> And, to summarize, we went through 3 ideas:
>
> 1. ioctl() - http://article.gmane.org/gmane.linux.kernel/1433933
> 2. syscall - http://article.gmane.org/gmane.linux.kernel/1437057
> 3. POSIX clock - below
>
> John also suggested that maybe the perf could use CLOCK_MONOTONIC_RAW
> instead of local/sched_clock().
Any chance a decision can be reached in time for 3.10? Seems like the
simplest option is the perf event based ioctl.
Converting/correlating perf_clock timestamps to time-of-day is a feature
I have been trying to get into perf for over 2 years. This is a big
piece needed for that goal -- along with the xtime tracepoints:
https://lkml.org/lkml/2013/3/19/433
David
next prev parent reply other threads:[~2013-03-31 16:24 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
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 [this message]
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=51586315.7080006@gmail.com \
--to=dsahern@gmail.com \
--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=peterz@infradead.org \
--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.