From: Ingo Molnar <mingo@elte.hu>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
Martin Bligh <mbligh@google.com>,
Peter Zijlstra <peterz@infradead.org>,
Martin Bligh <mbligh@mbligh.org>,
Steven Rostedt <rostedt@goodmis.org>,
linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
Andrew Morton <akpm@linux-foundation.org>,
prasad@linux.vnet.ibm.com,
Mathieu Desnoyers <compudj@krystal.dyndns.org>,
"Frank Ch. Eigler" <fche@redhat.com>,
David Wilder <dwilder@us.ibm.com>,
hch@lst.de, Tom Zanussi <zanussi@comcast.net>,
Steven Rostedt <srostedt@redhat.com>
Subject: Re: [RFC PATCH 1/3] Unified trace buffer
Date: Fri, 26 Sep 2008 00:25:48 +0200 [thread overview]
Message-ID: <20080925222548.GA28309@elte.hu> (raw)
In-Reply-To: <alpine.LFD.1.10.0809251448340.3265@nehalem.linux-foundation.org>
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> That said, if people think they can do a good job of ns conversion,
> I'll stop arguing. Quite frankly, I think people are wrong about that,
> and quite frankly, I think that anybody who looks even for one second
> at those "alternate" sched_clock() implementations should realize that
> they aren't suitable, but whatever. I'm not writing the code, I can
> only try to convince people to not add the insane call-chains we have
> now.
hm, i'd really hope hw makers see the light and actually make the hw do
it all. Signs are that they are cozying up to these ideas.
Good and fast timestamps are important, and it is _infinitely_ more easy
to do it in hw than in sw.
Firstly they need a low-frequency (10khz-100khz) shared clock line
across all CPUs. A single line - and since it's low frequency it could
be overlaid on some existing data line and filtered out. That works
across NUMA nodes as well and physics allows it to be nanosec accurate
up to dozens of meters or so. Then they need some really cheap way to
realize what absolute value the clock counts, and read it out every now
and then in the CPU, and approximate it inbetween, and have a secondary
stage cheap few-transitors long-latency multiplicator that keeps passing
on the nanosec-ish value to a register/MSR that can be read out by the
instruction.
This trivially works fine even if the CPU is turned off. It uses nary
any power as it's low freq, and can be spread across larger system
designs too. In fact it would be a totally exciting new capability for
things like analysis of SMP events. PEBS/BTS could be extended to save
this kind of timestamp, and suddenly one could see _very_ accurately
what happens between CPUs, without expensive bus snooping kit.
and CPUs wont go beyond the '~1nsec' event granularity for quite some
time anyway - so nanoseconds is not a time scale that gets obsoleted
quickly.
[ i guess this proves it that everyone has his pipe dream ;-) ]
Ingo
next prev parent reply other threads:[~2008-09-25 22:28 UTC|newest]
Thread overview: 109+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-24 5:10 [RFC PATCH 0/3] An Unified tracing buffer (attempt) Steven Rostedt
2008-09-24 5:10 ` [RFC PATCH 1/3] Unified trace buffer Steven Rostedt
2008-09-24 15:03 ` Peter Zijlstra
2008-09-24 15:44 ` Steven Rostedt
2008-09-25 10:38 ` Ingo Molnar
2008-09-24 15:47 ` Martin Bligh
2008-09-24 16:11 ` Peter Zijlstra
2008-09-24 16:24 ` Linus Torvalds
2008-09-24 16:37 ` Steven Rostedt
2008-09-24 16:56 ` Martin Bligh
2008-09-24 17:25 ` Linus Torvalds
2008-09-24 18:01 ` Mathieu Desnoyers
2008-09-24 20:49 ` Linus Torvalds
2008-09-24 16:26 ` Steven Rostedt
2008-09-24 16:49 ` Martin Bligh
2008-09-24 17:36 ` Linus Torvalds
2008-09-24 17:49 ` Steven Rostedt
2008-09-24 20:23 ` Linus Torvalds
2008-09-24 20:37 ` David Miller
2008-09-24 20:48 ` Steven Rostedt
2008-09-24 20:51 ` Martin Bligh
2008-09-24 21:24 ` Frank Ch. Eigler
2008-09-24 21:33 ` Steven Rostedt
2008-09-24 20:47 ` Steven Rostedt
2008-09-24 21:03 ` Martin Bligh
2008-09-24 21:17 ` Steven Rostedt
2008-09-24 21:51 ` Steven Rostedt
2008-09-25 10:41 ` Peter Zijlstra
2008-09-25 14:33 ` Martin Bligh
2008-09-25 14:53 ` Peter Zijlstra
2008-09-25 15:05 ` Linus Torvalds
2008-09-25 15:25 ` Martin Bligh
2008-09-25 15:36 ` Ingo Molnar
2008-09-25 16:23 ` Mathieu Desnoyers
2008-09-25 16:32 ` Steven Rostedt
2008-09-25 17:20 ` Mathieu Desnoyers
2008-09-25 17:32 ` Steven Rostedt
2008-09-25 16:40 ` Linus Torvalds
2008-09-25 16:53 ` Steven Rostedt
2008-09-25 17:07 ` Linus Torvalds
2008-09-25 19:55 ` Ingo Molnar
2008-09-25 20:12 ` Ingo Molnar
2008-09-25 20:24 ` Linus Torvalds
2008-09-25 20:29 ` Linus Torvalds
2008-09-25 20:47 ` Steven Rostedt
2008-09-25 21:01 ` Steven Rostedt
2008-09-25 21:10 ` Ingo Molnar
2008-09-25 21:16 ` Ingo Molnar
2008-09-25 21:41 ` Ingo Molnar
2008-09-25 21:56 ` Ingo Molnar
2008-09-25 21:58 ` Linus Torvalds
2008-09-25 22:14 ` Ingo Molnar
2008-09-25 23:33 ` Linus Torvalds
2008-09-27 17:16 ` Ingo Molnar
2008-09-27 17:36 ` Ingo Molnar
2008-09-27 17:38 ` Steven Rostedt
2008-09-27 17:50 ` Peter Zijlstra
2008-09-27 18:18 ` Steven Rostedt
2008-09-27 18:42 ` Ingo Molnar
2008-09-25 20:52 ` Ingo Molnar
2008-09-25 21:14 ` Jeremy Fitzhardinge
2008-09-25 21:15 ` Martin Bligh
2008-09-25 20:29 ` Mathieu Desnoyers
2008-09-25 20:20 ` Ingo Molnar
2008-09-25 21:02 ` Jeremy Fitzhardinge
2008-09-25 21:55 ` Linus Torvalds
2008-09-25 22:25 ` Ingo Molnar [this message]
2008-09-25 22:45 ` Steven Rostedt
2008-09-25 23:04 ` Jeremy Fitzhardinge
2008-09-25 23:25 ` Ingo Molnar
2008-09-26 14:04 ` Thomas Gleixner
2008-09-25 22:39 ` Jeremy Fitzhardinge
2008-09-25 22:55 ` Ingo Molnar
2008-09-26 1:17 ` Jeremy Fitzhardinge
2008-09-26 1:27 ` Steven Rostedt
2008-09-26 1:49 ` Jeremy Fitzhardinge
2008-09-25 22:59 ` Steven Rostedt
2008-09-26 1:27 ` Jeremy Fitzhardinge
2008-09-26 1:35 ` Steven Rostedt
2008-09-26 2:07 ` Jeremy Fitzhardinge
2008-09-26 2:25 ` Steven Rostedt
2008-09-26 5:31 ` Jeremy Fitzhardinge
2008-09-26 10:41 ` Steven Rostedt
2008-09-25 15:26 ` Steven Rostedt
2008-09-25 17:22 ` Linus Torvalds
2008-09-25 17:39 ` Steven Rostedt
2008-09-25 18:14 ` Linus Torvalds
2008-09-25 15:20 ` Steven Rostedt
2008-09-24 17:54 ` Martin Bligh
2008-09-24 18:04 ` Martin Bligh
2008-09-24 20:39 ` Linus Torvalds
2008-09-24 20:56 ` Martin Bligh
2008-09-24 21:08 ` Steven Rostedt
2008-09-24 20:30 ` Linus Torvalds
2008-09-24 20:53 ` Mathieu Desnoyers
2008-09-24 22:28 ` Linus Torvalds
2008-09-24 22:41 ` Linus Torvalds
2008-09-25 17:15 ` Mathieu Desnoyers
2008-09-25 17:29 ` Linus Torvalds
2008-09-25 17:42 ` Mathieu Desnoyers
2008-09-25 16:37 ` Mathieu Desnoyers
2008-09-25 16:49 ` Linus Torvalds
2008-09-25 17:02 ` Steven Rostedt
2008-09-24 16:13 ` Mathieu Desnoyers
2008-09-24 16:31 ` Steven Rostedt
2008-09-24 16:39 ` Peter Zijlstra
2008-09-24 16:51 ` Mathieu Desnoyers
2008-09-24 5:10 ` [RFC PATCH 2/3] ftrace: combine some print formating Steven Rostedt
2008-09-24 5:10 ` [RFC PATCH 3/3] ftrace: hack in the ring buffer Steven Rostedt
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=20080925222548.GA28309@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@linux-foundation.org \
--cc=compudj@krystal.dyndns.org \
--cc=dwilder@us.ibm.com \
--cc=fche@redhat.com \
--cc=hch@lst.de \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mbligh@google.com \
--cc=mbligh@mbligh.org \
--cc=peterz@infradead.org \
--cc=prasad@linux.vnet.ibm.com \
--cc=rostedt@goodmis.org \
--cc=srostedt@redhat.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=zanussi@comcast.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