From: Thomas Gleixner <tglx@linutronix.de>
To: John Stultz <john.stultz@linaro.org>
Cc: Stephane Eranian <eranian@google.com>,
Pawel Moll <pawel.moll@arm.com>,
Peter Zijlstra <peterz@infradead.org>,
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: Mon, 18 Feb 2013 21:35:57 +0100 (CET) [thread overview]
Message-ID: <alpine.LFD.2.02.1302182132230.22263@ionos> (raw)
In-Reply-To: <51118797.9080800@linaro.org>
On Tue, 5 Feb 2013, John Stultz wrote:
> On 02/05/2013 02:13 PM, Stephane Eranian wrote:
> > But if people are strongly opposed to the clock_gettime() approach, then
> > I can go with the ioctl() because the functionality is definitively needed
> > ASAP.
>
> I prefer the ioctl method, since its less likely to be re-purposed/misused.
Urgh. No! With a dedicated CLOCK_PERF we might have a decent chance to
put this into a vsyscall. With an ioctl not so much.
> Though I'd be most comfortable with finding some way for perf-timestamps to be
> CLOCK_MONOTONIC based (or maybe CLOCK_MONOTONIC_RAW if it would be easier),
> and just avoid all together adding another time domain that doesn't really
> have clear definition (other then "what perf uses").
What's wrong with that. We already have the infrastructure to create
dynamic time domains which can be completely disconnected from
everything else.
Tracing/perf/instrumentation is a different domain and the main issue
there is performance. So going for a vsyscall enabled clock_gettime()
approach is definitely the best thing to do.
Thanks,
tglx
next prev parent reply other threads:[~2013-02-18 20:36 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 [this message]
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
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=alpine.LFD.2.02.1302182132230.22263@ionos \
--to=tglx@linutronix.de \
--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 \
/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.