[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <33307c790809241351k53f322a1o794dd73255393e11@mail.gmail.com>
Date: Wed, 24 Sep 2008 13:51:55 -0700
From: "Martin Bligh" <mbligh@...gle.com>
To: "David Miller" <davem@...emloft.net>
Cc: torvalds@...ux-foundation.org, rostedt@...dmis.org,
peterz@...radead.org, linux-kernel@...r.kernel.org, mingo@...e.hu,
tglx@...utronix.de, akpm@...ux-foundation.org,
prasad@...ux.vnet.ibm.com, compudj@...stal.dyndns.org,
fche@...hat.com, dwilder@...ibm.com, hch@....de,
zanussi@...cast.net, srostedt@...hat.com
Subject: Re: [RFC PATCH 1/3] Unified trace buffer
>> So I'd like the thing to have small headers, and be designed from the
>> start to have small headers.
>
> Small headers are good, but I'd suggest making sure there is an
> "offset" or similar field in there.
>
> Not that I want to encourage frequent changes to header layout, but if
> you do need to add something, then this offset field allows you to do
> so while keeping existing analysis tools working. They will just
> ignore the new information in the headers, but they will still be able
> to get at the data bits using the offset.
One thing we said we could do is compile the "decompaction" tools
along with the kernel, in the kernel tree. Then if we change the in-kernel
format, you don't break all the userspace tools. We used:
struct ktrace_time {
u32 seconds;
u32 nanoseconds;
};
struct ktrace_event {
struct ktrace_time time;
u16 cpu;
u16 type;
u32 pid;
u32 data;
u32 elapsed_time; /* ns for interrupt, otherwise us */
u32 expanded_length;
}
The format is much easier to parse for userspace tools, though much
less compact. A simple C tool can turn in-kernel format into userspace
format:
1. Merge the per-cpu buffers into a single stream
2. put cpu ids in
3. Work out which pid was running, from the last context switch
4. Put in elapsed times (keeping track of the start of a system call
and recording the delta at end of system call (or interrupt, etc))
--
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