The old "lock always" scheme had issues with lockdep, and was not very
efficient anyways.

This patch does a new design to be partially lockless on writes.
Writes will add new entries to the per cpu pages by simply disabling
interrupts. When a write needs to go to another page than it will
grab the lock.

A new "read page" has been added so that the reader can pull out a page
from the ring buffer to read without worrying about the writer writing over
it. This allows us to not take the lock for all reads. The lock is
now only taken when a read needs to go to a new page.

This is far from lockless, and interrupts still need to be disabled,
but it is a step towards a more lockless solution, and it also
solves a lot of the issues that were noticed by the first conversion
of ftrace to the ring buffers.

Note: the ring_buffer_{un}lock API has been removed.

Signed-off-by: Steven Rostedt <srostedt@redhat.com>
---
 include/linux/ring_buffer.h |    3 
 kernel/trace/ring_buffer.c  |  298 +++++++++++++++++++++++++-------------------
 kernel/trace/trace.c        |  113 +++++++++++-----
 3 files changed, 247 insertions(+), 167 deletions(-)

Index: linux-tip.git/include/linux/ring_buffer.h
===================================================================
--- linux-tip.git.orig/include/linux/ring_buffer.h	2008-09-30 20:48:32.000000000 -0400
+++ linux-tip.git/include/linux/ring_buffer.h	2008-09-30 20:49:30.000000000 -0400
@@ -63,9 +63,6 @@ ring_buffer_event_time_delta(struct ring
 	return event->time_delta;
 }
 
-void ring_buffer_lock(struct ring_buffer *buffer, unsigned long *flags);
-void ring_buffer_unlock(struct ring_buffer *buffer, unsigned long flags);
-
 /*
  * size is in bytes for each per CPU buffer.
  */
Index: linux-tip.git/kernel/trace/ring_buffer.c
===================================================================
--- linux-tip.git.orig/kernel/trace/ring_buffer.c	2008-09-30 20:48:32.000000000 -0400
+++ linux-tip.git/kernel/trace/ring_buffer.c	2008-09-30 ...
[ message continues ]

applied to tip/tracing/ring-buffer, thanks Steve!

the simplification factor is significant as well - both in linecount and 
in locking complexity. A robust tracer almost never wants to impose 
heavy locking semantics - a good way to disable/enable it on a per CPU 
basis is more than enough to 'freeze' the trace and get it out to the 
user.

Perhaps, before we free trace buffers, we should do an RCU sync to make 
sure no access can linger? Right now we dont seem to free buffers 
anywhere.

	Ingo
--

[ message continues ]