Re: [PATCH 2/2] ring_buffer: implement new locking

[Ingo Molnar <mingo@elte.hu>]

* Steven Rostedt <rostedt@goodmis.org> wrote:

> 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(-)

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