From: Linus Torvalds <torvalds@linux-foundation.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
Martin Bligh <mbligh@google.com>,
linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
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: Wed, 24 Sep 2008 10:25:57 -0700 (PDT) [thread overview]
Message-ID: <alpine.LFD.1.10.0809241014250.3265@nehalem.linux-foundation.org> (raw)
In-Reply-To: <alpine.DEB.1.10.0809241231520.5017@gandalf.stny.rr.com>
On Wed, 24 Sep 2008, Steven Rostedt wrote:
>
> The event counter is just the timestamp (quick patch, simple to fix). The
> term "counter" was bad. It should have been timestamp, which one would
> want a 64bit timestamp.
One definitely would _not_ want the full 64-bit timestamp.
There are two cases:
- lots and lots of events
just do a 32 bit "timestamp delta" to the previous packet (where the
first packet in the queue would be a delta from a value in the queue
header - and we can obviously make that value be the TSC so that the
first delta is always zero, but it may also make sense to make it a
real delta, and the queue header would contain some good
synchronization point value).
- occasional events
Oops. The delta wouldn't fit. So create a new "timestamp update" packet
with a 64-bit thing when doing the reservation. There's obviously no
cost issue (since this would only happen for things where there was a
multi-second delay - or at least an appreciable fraction of a delay -
between events)
This definitely is worth doing. If we have small trace objects (and many
things really do have pretty small traces), using just a 32-bit TSC not
only saves 4 bytes per trace event, but it makes it quite reasonable to
keep the trace data 4-byte-aligned rather than requiring 8-byte alignment.
Of course, if the traces end up being horribly bloated, none of that will
matter. But I really would hope that you we keep the header itself to just
8 bytes (and being 2 4-byte entities), so that small payloads are
reasonable. And that looks doable, if you have a 16-bit "type" and a
16-bit "size" field.
One thing I'd like to do is to also architecturally reserve a few of the
types for internal queue management stuff. Things like "padding" objects
(or a "end-of-ringbuffer" object), and the TSC overflow object, and a
"time sync" object (or heartbeat). So maybe the type would have the high
bit set as a "reserved for internal ringbuffer use" or whatever.
Linus
next prev parent reply other threads:[~2008-09-24 17:34 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 [this message]
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
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=alpine.LFD.1.10.0809241014250.3265@nehalem.linux-foundation.org \
--to=torvalds@linux-foundation.org \
--cc=akpm@linux-foundation.org \
--cc=compudj@krystal.dyndns.org \
--cc=dwilder@us.ibm.com \
--cc=fche@redhat.com \
--cc=hch@lst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mbligh@google.com \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=prasad@linux.vnet.ibm.com \
--cc=rostedt@goodmis.org \
--cc=srostedt@redhat.com \
--cc=tglx@linutronix.de \
--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
Powered by JetHome