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

[Martin Bligh]

>> Most people will want the events to be as _small_ as humanly possible. The
>> normal event size should hopefully be in the 8-16 bytes, and I think the
>> RFC patch is already broken because it allocates that insane 64-bit event
>> counter for things. Who the hell wants a 64-bit event counter that much?
>> That's broken.
>
> The event counter is just the timestamp (quick patch, simple to fix). The
> term "counter" was bad. It should have been timestamp, which one would
> want a 64bit timestamp. Or at least a way to figure it out. Yes, we can
> store a special event called "timestamp" and have a smaller counter. But
> for simplicity, the 64 bit was easy. The event id was just 16 bits, which
> I think is way more than enough.

Yup, is just a confusing name. we can definitely make this a smaller field
by doing an offset time from the last event, but we agreed on 64 bits to
keep version 1 simple ;-)

I think in retrospect the timestamp events we used with wall time stuck
in them were a mistake, as NTP will make them difficult. We should have
just recorded wall time at the start of the buffer, and done offsets from
there.

Without relayfs subbuffers, the offset thing gets trickier, as you'd have
to update the "start time" constantly once you'd filled the buffer and
were shifting the start pointer. OTOH, I guess it's only 1 cacheline.

M.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/