From: Steven Rostedt <rostedt@goodmis.org>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Frederic Weisbecker <fweisbec@gmail.com>,
Ingo Molnar <mingo@elte.hu>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Huang, Ying" <ying.huang@intel.com>,
"bp@alien8.de" <bp@alien8.de>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"mchehab@redhat.com" <mchehab@redhat.com>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Arjan van de Ven <arjan@infradead.org>
Subject: RE: Tracing Requirements (was: [RFC/Requirements/Design] h/w error reporting)
Date: Wed, 10 Nov 2010 16:06:34 -0500 [thread overview]
Message-ID: <1289423194.12418.195.camel@gandalf.stny.rr.com> (raw)
In-Reply-To: <987664A83D2D224EAE907B061CE93D5301649A71DC@orsmsx505.amr.corp.intel.com>
On Wed, 2010-11-10 at 12:54 -0800, Luck, Tony wrote:
> >- Perf does not support flight recorder tracing (concurrent read/write)
> > - Sub-buffers are needed to support concurrent read/writes
>
> When I hear somebody say "flight recorder" - I think of "black boxes"
> in airplanes that log data while the flight is running, and are only
> looked at offline later. So I'm confused by the "concurrent read/write"
> requirement.
>
> Perhaps you could explain the use cases of your "flight recorder",
> because it seems that the name doesn't fit exactly, and this is
> causing me (and maybe others) some confusion.
Hmm, I had this argument with Mathieu before, but I guess I mistakenly
let him win ;-)
I call "flight recorder" mode "overwrite" mode. Basically there's two
modes. They only have meaning when the ring buffer is full and a write
takes place.
1) produce/consumer mode - When the writer reaches the reader, all new
events are discarded. This means that you lose the latest events while
you keep older events around.
2) overwrite mode (flight recorder) - when the writer reaches the
reader, it pushes the reader forward, and writes the new events over the
old ones. This way, new events are always existent, where as old events
are lost.
1 is much easier to implement than 2, especially when doing it in a
lockless way.
I guess I should have fought harder to keep the terminology of
"overwrite" mode. This is the third time is the last week I had to
explain what "flight recorder" mode was. Where as, overwrite mode was a
bit more obvious.
-- Steve
next prev parent reply other threads:[~2010-11-10 21:06 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-10 0:56 [RFC/Requirements/Design] h/w error reporting Luck, Tony
2010-11-10 10:14 ` Ingo Molnar
2010-11-10 14:40 ` Steven Rostedt
2010-11-10 14:43 ` Peter Zijlstra
2010-11-10 15:09 ` Steven Rostedt
2010-11-10 15:28 ` Mathieu Desnoyers
2010-11-10 15:30 ` Peter Zijlstra
2010-11-10 15:53 ` Steven Rostedt
2010-11-10 16:52 ` Steven Rostedt
2010-11-10 17:05 ` Borislav Petkov
2010-11-10 17:41 ` Ingo Molnar
2010-11-10 17:50 ` Luck, Tony
2010-11-10 18:09 ` Steven Rostedt
2010-11-10 18:52 ` Ingo Molnar
2010-11-10 17:25 ` Frederic Weisbecker
2010-11-10 17:48 ` Ingo Molnar
2010-11-10 18:05 ` Steven Rostedt
2010-11-10 18:23 ` Luck, Tony
2010-11-10 18:31 ` Peter Zijlstra
2010-11-10 18:49 ` Ingo Molnar
2010-11-10 18:24 ` Peter Zijlstra
2010-11-10 18:41 ` Ingo Molnar
2010-11-10 19:00 ` Steven Rostedt
2010-11-10 19:11 ` Ingo Molnar
2010-11-10 19:11 ` Frederic Weisbecker
2010-11-10 19:30 ` Ingo Molnar
2010-11-10 19:48 ` Steven Rostedt
2010-11-10 20:23 ` Tracing Requirements (was: [RFC/Requirements/Design] h/w error reporting) Mathieu Desnoyers
2010-11-10 20:54 ` Luck, Tony
2010-11-10 21:06 ` Steven Rostedt [this message]
2010-11-10 21:34 ` Steven Rostedt
2010-11-10 22:51 ` Mathieu Desnoyers
2010-11-10 23:12 ` Thomas Gleixner
2010-11-10 23:20 ` Steven Rostedt
2010-11-10 23:45 ` Thomas Gleixner
2010-11-11 18:25 ` Ted Ts'o
2010-11-10 23:28 ` Mathieu Desnoyers
2010-11-10 23:58 ` Thomas Gleixner
2010-11-11 9:17 ` Ingo Molnar
2010-11-11 13:37 ` Mathieu Desnoyers
2010-11-10 21:30 ` Frederic Weisbecker
2010-11-10 21:54 ` Steven Rostedt
2010-11-10 22:19 ` Frederic Weisbecker
2010-11-10 22:49 ` Frederic Weisbecker
2010-11-11 0:11 ` Mathieu Desnoyers
2010-11-11 16:10 ` Steven Rostedt
2010-11-11 16:34 ` Mathieu Desnoyers
2010-11-10 19:16 ` [RFC/Requirements/Design] h/w error reporting Steven Rostedt
2010-11-10 19:38 ` Steven Rostedt
2010-11-10 18:27 ` Ingo Molnar
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=1289423194.12418.195.camel@gandalf.stny.rr.com \
--to=rostedt@goodmis.org \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=arjan@infradead.org \
--cc=bp@alien8.de \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mchehab@redhat.com \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=ying.huang@intel.com \
/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
all inboxes | Powered by JetHome®