Re: [PATCH] ring_buffer: enlarge RB_MAX_SMALL_DATA

[Ingo Molnar <mingo@elte.hu>]

* Steven Rostedt <srostedt@redhat.com> wrote:

> 
> On Wed, 2009-04-15 at 17:14 +0800, Lai Jiangshan wrote:
> 
> > 
> > How about this method:
> > 
> > {u32 type_len:5, time_delta:27;};
> > 
> > time_delta is still 27bits, but RB_MAX_SMALL_DATA is increased to 112,
> > it is larger than 60 in my patch.
> > 
> > type_len  actual type                actual len
> > 0         RINGBUF_TYPE_DATA,         array[0]
> > 1 ~ 28    RINGBUF_TYPE_DATA          4*1 ~ 4*28
> > 29        RINGBUF_TYPE_TIME_STAMP    
> > 30        RINGBUF_TYPE_TIME_EXTEND
> > 31        RINGBUF_TYPE_PADDING       array[0] if it's not the last event
> >                                      in the buffer_page(discarded event)
> > If you like this method, I will implement it.
> 
> I like the idea a lot. The only issue I have with it is that these types
> are used a lot in switch statements, and in fast paths.
> 
> But the compression may be a better win.
> 
> We could do this in the switches.
> 
> 	switch (event->type_len) {
> 	case RINGBUF_TYPE_TIME_STAMP:
> 		/**/
> 		break;
> 	case RINGBUF_TYPE_TIME_EXTEND:
> 		/**/
> 		break;
> 	case RINGBUF_TYPE_PADDING:
> 		/**/
> 		break;
> 	default: /* RINGBUF_TYPE_DATA */
> 
> 	}
> 
> But before any of this goes in. I would like to export the 
> interface. Yes it is suppose to be OK to be able to change the 
> interface, but the binary output made it into 30. I doubt this 
> change will make it before 31. If that's the case. We must have 
> the format listed. 30 is expected to be used by many distros. 
> There's already tools using ftrace. If we make a change that can 
> not be caught, then it will break many tools.

Yeah - format specifications are always good. They weaken ABI 
bindings and allow more flexibility both on the tool and the kernel 
side.

> We could ask Linus to pull this into 30 because it is a API 
> change.

Apps could assume if the format file is not there it's the .30 
format.

	Ingo