Re: LTTng format
Mathieu Desnoyers <[email protected]> Tue, 18 Sep 2007 09:01:48 -0400
| Newsgroups | gmane.linux.kernel.tracing |
|---|---|
| Message-ID | <20070918130148.GA20507@Krystal> |
* Raghavendra Rao ([email protected]) wrote: > Hello Matheu, > Here are my questions. > 1. What is the link between the tags in the .xml files with trace > files? Will these files be used by LTTV to interpret the trace data? If > so, how? Hi, In the "stable" LTTng versions, the XML files contain information about the data types of each events, organized by "facility" (group of events). They are used by LTTV to get the type information required to read the event-specific fields. It must (in the stable version, again), be kept up to date, and declare the events in the same order, as the "probe" module in the kernel. (see ltt/probes/*) > 2. buf_size: Does this indicate the size of each block in the trace > file? How to know how many blocks exist in a trace file? Yes. file size / buf size. > 3. facility_id, event_id: How this is related between the > control/cpu trace files? Except for the "compact" tracefile, which is a particular case, facility_ids are global to the whole kernel, recorded in any control or cpu trace file. Event IDs are assigned statically within a facility. Only the facilities channel must _only_ contain facility load/unload events and heartbeat events, because it must be parsed at trace load time by LTTV so type information (from the XML) can be connected to the facility IDs (with facility load events). > 4. event data: What does each event data in each block of trace > file indicate? How to interpret this data? The XML file describes that. The link between the facility_id/event_id and facility name/checksum (and therefore xml file) is done by the facility load events. in the facilities tracefile. > 5. What is the link between data from one trace file with other > trace file? (say cpu_0 with facilities_0 or interrupts_0 trace files or > any trace files for that matter) > All of those share the same timestamps. The fact that the information is spliited in multiple channels is used to speed up some computation that would be done on a smaller quantity of data and to split important vs less important information to gather hybrid (flight recorder and normal) traces. Note that the facilities channel, as I just said previously, is a bit particular. I hope it clarify things, thanks for asking. If I am not clear in some aspects, please ask. Mathieu > If you prefer to see the trace data which I obtained, I can share with > you. > > Thanks and regards > Raghavendra. > > -----Original Message----- > From: Mathieu Desnoyers [mailto:[email protected]] > Sent: Wednesday, September 12, 2007 10:36 PM > To: Raghavendra Rao > Cc: [email protected] > Subject: Re: [Ltt-dev] LTTng format > > * Raghavendra Rao ([email protected]) wrote: > > Hello Mathieu > > I need info on the LTTng trace formats. > > I have format info from > > http://ltt.polymtl.ca/svn/ltt/branches/poly/doc/developer/format.html > > > > I tried to correlate the format information between the actual trace > > files (which I got from LTTng) and what is viewed on LTTV. > > I opened the trace files (with an editor which can open binary files) > > and tried mapping the data with the format and with what is displayed > on > > the viewer. > > I can not make out the offset at which they (each data that is > displayed > > in the viewer) are present in the trace files. > > > > Can you point me to some appropriate document. > > > > You have the right pointer. Can you give me an example of what field you > are looking for in the trace and how you try to calculate the offsets ? > > > > Thanks and regards > > Raghavendra. > > > > > > > > _______________________________________________ > > Ltt-dev mailing list > > [email protected] > > http://listserv.shafik.org/mailman/listinfo/ltt-dev > > > > -- > Mathieu Desnoyers > Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal > OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE > 9A68 > -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68