From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: "Ingo Molnar" <mingo@elte.hu>, "Luck, Tony" <tony.luck@intel.com>,
linux-kernel@vger.kernel.org, ying.huang@intel.com, bp@alien8.de,
tglx@linutronix.de, akpm@linux-foundation.org,
mchehab@redhat.com, "Frédéric Weisbecker" <fweisbec@gmail.com>,
"Arnaldo Carvalho de Melo" <acme@redhat.com>,
"Arjan van de Ven" <arjan@infradead.org>,
"Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>
Subject: Re: [RFC/Requirements/Design] h/w error reporting
Date: Wed, 10 Nov 2010 16:30:19 +0100 [thread overview]
Message-ID: <1289403019.2084.17.camel@laptop> (raw)
In-Reply-To: <1289401781.12418.145.camel@gandalf.stny.rr.com>
On Wed, 2010-11-10 at 10:09 -0500, Steven Rostedt wrote:
>
> > sure the second way is the only way out, but you still need to come up
> > with a trace data format and a control ABI.
>
> Great! Let's start with that then. Could you list some of the basic
> needs of perf?
Needs for what? I've already got a full control ABI and I can already
redirect output to other buffers ;-)
I don't have enumeration of what all is redirected to what, I pretend
that people know wth they're doing.. so if you want session lists of
what tracepoints are active on which buffers and the like you'll have to
come up with something for that.
As for the buffer, I prefer a u64 aligned data stream, but the very
least I need is frame encapsulation. What I don't want _ever_ is stupid
sub-buffers. And no they're not needed, see the discussion about sync
markers a while back.
I also don't want to support the stupid concurrent read/write from tail.
What I do want is both mmap() and splice(), this means buffer size needs
to be specified at buffer creation.
I currently support overwrite (flight-recorder) and non-overwrite modes
depending on PROT_WRITE, I guess that can easily be pushed into the
buffer create call.
As to the mmap() part, it needs a control page to expose the head/tail
pointers and some data.
And as you know I need to write > PAGE_SIZE entries.
next prev parent reply other threads:[~2010-11-10 15:30 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 [this message]
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
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=1289403019.2084.17.camel@laptop \
--to=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=rostedt@goodmis.org \
--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