[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.1.10.0809241748220.10631@gandalf.stny.rr.com>
Date: Wed, 24 Sep 2008 17:51:43 -0400 (EDT)
From: Steven Rostedt <rostedt@...dmis.org>
To: Martin Bligh <mbligh@...gle.com>
cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Peter Zijlstra <peterz@...radead.org>,
linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
Thomas Gleixner <tglx@...utronix.de>,
Andrew Morton <akpm@...ux-foundation.org>,
prasad@...ux.vnet.ibm.com,
Mathieu Desnoyers <compudj@...stal.dyndns.org>,
"Frank Ch. Eigler" <fche@...hat.com>,
David Wilder <dwilder@...ibm.com>, hch@....de,
Tom Zanussi <zanussi@...cast.net>,
Steven Rostedt <srostedt@...hat.com>
Subject: Re: [RFC PATCH 1/3] Unified trace buffer
On Wed, 24 Sep 2008, Martin Bligh wrote:
>
> How about we just steal 5 bits from the timestamp to indicate event
> lengths up to 32 bytes, and if it's 0, that means there's a length
> field following? Also that'd mean you could use a longer length field
> and get beyond 256 bytes to 4096, without impacting most events.
>
> struct {
> u32 length:5, time_delta:27;
> u16 length;
> u8 buf[];
> };
>
> struct {
> u32 length:5, time_delta:27; /* where length == 0 */
> u8 buf[];
> };
BTW, if we declare the ring buffer to have fixed length entries, do we
still want to record the length?
Hmm, probably should. It would make the code easier. If it is fixed length
under 256 bytes, we still need to record the timestamp, and the length is
only 5 bits. It could probably store something else, but we can leave that
for version two ;-)
Heck, for now, I'll remove the work I did to add the fix length option,
and just use this default. If you have fixed length entries, it will
just make it easier to code the above layers.
-- Steve
--
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/
Powered by blists - more mailing lists