From: David Ahern <dsahern@gmail.com>
To: Stephane Eranian <eranian@google.com>
Cc: John Stultz <john.stultz@linaro.org>,
Pawel Moll <pawel.moll@arm.com>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
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, 03 Apr 2013 08:14:20 -0600 [thread overview]
Message-ID: <515C393C.8030405@gmail.com> (raw)
In-Reply-To: <CABPqkBS_z8zzSn=N_Q+AGbo1kV2EMOoF4dz2Aze=rPNB2n_n2g@mail.gmail.com>
On 4/3/13 8:00 AM, Stephane Eranian wrote:
>> What's the advantage of changing apps -- like the JIT compiler -- to emit
>> perf based timestamps versus having perf emit existing timestamps? ie.,
>> monotonic and realtime clocks already have vdso mappings for userspace with
>> well known performance characteristics. Why not have perf convert its
>> perf_clock timestamps into monotonic or realtime when dumping events?
>>
> Can monotonic timestamps be obtained from NMI context in the kernel?
I don't understand the context of the question.
I am not suggesting perf_clock be changed. I am working on correlating
existing perf_clock timestamps to clocks typically used by apps
(REALTIME and time-of-day but also applies to MONOTONIC).
You are wanting the reverse -- have apps emit perf_clock timestamps. I
was just wondering what is the advantage of this approach?
David
next prev parent reply other threads:[~2013-04-03 14:14 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
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 [this message]
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=515C393C.8030405@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.