lkml.org 
[lkml]   [2008]   [Sep]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC PATCH 1/3] Unified trace buffer
    > OK, then how about this?
    >
    > Each page will start with a time stamp (I'm still aligning everything by 8
    > bytes, just because it simplifies things). Then we can have a 3 byte
    > (24 bit) counter offset? Then we can have a header that looks like:
    >
    > struct {
    > unsigned char time[3];
    > unsigned char length;
    > unsigned char buff[];
    > };
    >
    > This still allows me to have the 2048 byte size buffer.
    >
    > Or is 24 bits for time too small? The offest will be from the previous
    > entry, and not the beginning of the page.
    >
    > If one defines a fixed size entry, we could just use the full 32 bits for
    > the timestamp, since the length will be ignored in that case, and will
    > become part of the buffer.
    >
    > Hence,
    >
    > struct {
    > unsigned int time;
    > unsigned char length;
    > unsigend char buff[];
    > };

    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[];
    };

    Obviously we could less than 5 bits, even just 1 for a flag ...


    \
     
     \ /
      Last update: 2008-09-24 23:05    [W:4.722 / U:0.000 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site