Messages in this thread | | | Date | Wed, 24 Sep 2008 08:47:42 -0700 | From | "Martin Bligh" <> | Subject | Re: [RFC PATCH 1/3] Unified trace buffer |
| |
Thanks for creating this so quickly ;-)
>> We can record either the fast way of reserving a part of the buffer: >> >> event = ring_buffer_lock_reserve(buffer, event_id, length, &flags); >> event->data = record_this_data; >> ring_buffer_unlock_commit(buffer, event, flags); > > This can, in generic, not work. Due to the simple fact that we might > straddle a page boundary. Therefore I think its best to limit our self > to the write interface below, so that it can handle that.
I'm not sure why this is any harder to deal with in write, than it is in reserve? We should be able to make reserve handle this just as well?
If you use write rather than reserve, you have to copy all the data twice for every event.
> On top of that foundation build an eventbuffer, which knows about > encoding/decoding/printing events. > > This too needs to be a flexible layer -
That would be nice. However, we need to keep at least the length and timestamp fields common so we can do parsing and the mergesort?
+struct ring_buffer_event { + unsigned long long counter; + short type; + short length; + char body[]; +} __attribute__((__packed__))
So type would move into the body here?
> as I suspect the google guys > will want their ultra-compressed events back.
Is useful when gathering GB of data across 10,000 machines ;-) Also reduces general overhead for everyone to keep events small.
| |