linux-kernel - Re: [PATCH] ring_buffer: enlarge RB_MAX_SMALL

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 15 Apr 2009 16:12:21 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Steven Rostedt <srostedt@...hat.com>
Cc:	Lai Jiangshan <laijs@...fujitsu.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ring_buffer: enlarge RB_MAX_SMALL_DATA


* Steven Rostedt <srostedt@...hat.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/