linux-kernel - Re: Tracing Requirements (was: [RFC/Requirements/Design] h/w error reporting)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 11 Nov 2010 11:34:15 -0500
From:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	"Luck, Tony" <tony.luck@...el.com>, linux-kernel@...r.kernel.org,
	ying.huang@...el.com, bp@...en8.de, tglx@...utronix.de,
	akpm@...ux-foundation.org, mchehab@...hat.com,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: Tracing Requirements (was: [RFC/Requirements/Design] h/w error
	reporting)

* Steven Rostedt (rostedt@...dmis.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/