From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>,
Ingo Molnar <mingo@elte.hu>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
"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, 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: Thu, 11 Nov 2010 11:34:15 -0500 [thread overview]
Message-ID: <20101111163415.GB11348@Krystal> (raw)
In-Reply-To: <1289491816.12418.255.camel@gandalf.stny.rr.com>
* Steven Rostedt (rostedt@goodmis.org) wrote:
> On Wed, 2010-11-10 at 19:11 -0500, Mathieu Desnoyers wrote:
>
> > > There are also the other common fields:
> > >
> > > struct trace_entry {
> > > unsigned short type;
> > >
> > >
> > > Type is needed by perf. If we have one buffer per event, we could
> > > retrieve which event we are dealing with. But if buffers are
> > > multiplexed per cpu, we need this.
> >
> > Agreed, although 65536 types ID is probably overkill for the common case.
> > I prefer to go for approaches with a header that contains a smaller number of
> > bits, and use an extended header for those rare cases that need it.
>
> Note, ftrace currently has over 600 event types. Unless we compact it
> down into bits, using two bytes is fine.
I understand that overall the numer of events overflows 256. However, this does
not mean they are typically all activated. Moreover, if we add multiple buffer
support, these events don't necessarily have to end up in the same buffer. This
numeric identifier is only there to distinguish between events ending in the
same buffer after all.
So the number of available events does not count as an argument for choosing the
typical number of bytes to represent the event IDs. The number of events
typically activated for a trace session does.
Thanks,
Mathieu
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
next prev parent reply other threads:[~2010-11-11 16:34 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
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 [this message]
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=20101111163415.GB11348@Krystal \
--to=mathieu.desnoyers@efficios.com \
--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=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