[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.1.10.0812161432000.23871@gandalf.stny.rr.com>
Date: Tue, 16 Dec 2008 14:38:44 -0500 (EST)
From: Steven Rostedt <rostedt@...dmis.org>
To: Robert Richter <robert.richter@....com>
cc: LKML <linux-kernel@...r.kernel.org>,
oprofile-list <oprofile-list@...ts.sourceforge.net>,
Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH 6/9] oprofile: port to the new ring_buffer
On Tue, 16 Dec 2008, Robert Richter wrote:
>
> In the beginning, the use of separate locks for reading and writing
> would be sufficient. Then, there would be only one atomic comparison
> needed to check, if the write pointer meets the read pointer. This
> should be not as difficult since read and write is always in different
> pages (if a am not wrong) and thus only the pointer to the pages have
> to be compared.
>
Most of the ftrace work uses the ring buffer in overwrite mode. That is,
when the head meets the tail, we move the tail. The way the reader works,
is that the first read will swap a page out of the ring with a blank page.
This means, what is on that page is safe from further writes. When the
reader is finished with the page, it will swap the empty page with a tail
of the buffer.
The problem is that there needs to be a lock to protect this change. If
the writer is moving the tail and the reader is about to swap it, things
can get corrupted. There are tricks to protect this with cmpxchg, but for
now we are playing it safe with spin locks. Note, the lock is only taken
by the reader when it needs to go to the next page.
The writers do not need any locks to protect against other writers,
because the buffers are per cpu and a write may only be performed on a
buffer on the local cpu.
-- Steve
Note: I may have tail and head backwards, I do not remember which end I
called what.
--
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/
Powered by blists - more mailing lists