Messages in this thread | | | Date | Wed, 24 Sep 2008 10:36:06 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: [RFC PATCH 1/3] Unified trace buffer |
| |
On Wed, 24 Sep 2008, Martin Bligh wrote: > > Can't the reserve interface just put a padding event into page A, > or otherwise mark it, and return the start of page B?
Yes, I think having a "padding" entry that just gets skipped on read would simplify things. Use that to fill up the end of the page.
> > And here I was thinking you guys bit encoded the event id into the > > timestamp delta :-) > > +/* header plus 32-bits of event data */ > +struct ktrace_entry { > + u32 event_type:5, tsc_shifted:27; > + u32 data; > +}; > > was our basic data type. So ... sort of ;-)
Why "tsc_shifted"?
I think 27 bits is probably fine, but not by removing precision. Instead of shifting it so it will fit (and dropping low bits as uninteresting), do it by encoding it as a delta against the previous thing. 27 bits would still be sufficient for any high-performance thing that has tons and tons of packets, and if you only have a few trace events you can afford to have the "TSC overflow" event type (and if you want it that dense, you could just make 'data' be the high bits, for a total of 59 bits rather than 64 bits of TSC.
59 bits of cycle counters is perfectly fine unless you are talking trace events over a year or so (I didn't do the math, but let's assume a 4GHz TSC as a reasonable thing even going forward - even _if_ CPU's get faster than that, the TSC is unlikely to tick faster since it's just not worth it from a power standpoint).
Ok, I did the math. 1<<27 seconds (assuming the low 32 bits are just fractions) is something like 4+ years. I _really_ don't think we need more than that (or even close to that) in TSC timestamps for tracing within one single buffer.
Once you go to the next ring buffer, you'd get a new time-base anyway.
Linus
| |