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
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.


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