Re: [RFC PATCH 1/3] Unified trace buffer

[Linus Torvalds <torvalds@linux-foundation.org>]

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