[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <33307c790809191457y3ebffa28xa6d9ab6431554618@mail.gmail.com>
Date: Fri, 19 Sep 2008 14:57:56 -0700
From: "Martin Bligh" <mbligh@...gle.com>
To: "Randy Dunlap" <randy.dunlap@...cle.com>
Cc: "Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
"Linus Torvalds" <torvalds@...ux-foundation.org>,
"Thomas Gleixner" <tglx@...utronix.de>,
"Mathieu Desnoyers" <compudj@...stal.dyndns.org>,
"Steven Rostedt" <rostedt@...dmis.org>, od@...ell.com,
"Frank Ch. Eigler" <fche@...hat.com>
Subject: Re: Unified tracing buffer
>> Event ids are 16 bit, dynamically allocated.
>
> What are these (like)?
u16
Sorry, probably lots of implicit assumptions in there that I forgot to explain
> Arch-specific "word"?
> or some fixed-size-for-all-systems (so that trace buffers can be
> shared/used on other systems?) Preferably the latter.
Mmmm. I don't see anything wrong with making it just 8 byte aligned, personally.
Steven - this was your thing?
>> Variable record length, header will start with length record.
>> Timestamps in fixed timebase, monotonically increasing (across all CPUs)
>
> what timestamp resolution?
ns is probably sufficient for output, but may need to be higher
internally to get
correct ordering of events across CPUs. So, as long as we record this in
the buffer header, the internal resolution shouldn't be critical. The text
print output ... I'd say ns? We can put it relative to wall time in there,
as long as we record it in the buffer header at trace start. I guess we should
document the buffer header ;-)
--
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