All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert Richter <robert.richter@amd.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	oprofile-list <oprofile-list@lists.sourceforge.net>,
	Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH 6/9] oprofile: port to the new ring_buffer
Date: Tue, 16 Dec 2008 18:23:42 +0100	[thread overview]
Message-ID: <20081216172341.GK15411@erda.amd.com> (raw)
In-Reply-To: <alpine.DEB.1.10.0812111424470.24741@gandalf.stny.rr.com>

On 11.12.08 14:48:56, Steven Rostedt wrote:
> > Since the new tracing ring buffer implementation uses spin locks to
> > protect the buffer during read/write access, it is difficult to use
> > the buffer in an NMI handler. In this case, writing to the buffer by
> > the NMI handler (x86) could occur also during critical sections when
> > reading the buffer. To avoid this, there are 2 buffers for independent
> > read and write access. Read access is in process context only, write
> > access only in the NMI handler. If the read buffer runs empty, both
> > buffers are swapped atomically. There is potentially a small window
> > during swapping where the buffers are disabled and samples could be
> > lost.
> 
> There is plans on removing the spinlock from the write side of the buffer.
> But this will take a bit of work and care. Lockless is better, but it also 
> makes for more complex code which translates to more prone to bugs code.

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.

-Robert

-- 
Advanced Micro Devices, Inc.
Operating System Research Center
email: robert.richter@amd.com


  reply	other threads:[~2008-12-16 17:24 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-11 16:41 [PATCH 0/9] oprofile: port to the new ring buffer Robert Richter
2008-12-11 16:41 ` [PATCH 1/9] oprofile: adding cpu buffer r/w access functions Robert Richter
2008-12-11 16:41 ` [PATCH 2/9] oprofile: adding cpu_buffer_write_commit() Robert Richter
2008-12-11 16:41 ` [PATCH 3/9] oprofile: adding cpu_buffer_entries() Robert Richter
2008-12-11 16:41 ` [PATCH 4/9] oprofile: moving cpu_buffer_reset() to cpu_buffer.h Robert Richter
2008-12-11 16:41 ` [PATCH 5/9] ring_buffer: add remaining cpu functions to ring_buffer.h Robert Richter
2008-12-11 19:23   ` Steven Rostedt
2008-12-11 16:42 ` [PATCH 6/9] oprofile: port to the new ring_buffer Robert Richter
2008-12-11 19:48   ` Steven Rostedt
2008-12-16 17:23     ` Robert Richter [this message]
2008-12-16 19:38       ` Steven Rostedt
2008-12-16  9:37   ` Andrew Morton
2008-12-11 16:42 ` [PATCH 7/9] oprofile: remove nr_available_slots() Robert Richter
2008-12-11 16:42 ` [PATCH 8/9] oprofile: fix lost sample counter Robert Richter
2008-12-11 16:42 ` [PATCH 9/9] ring_buffer: adding EXPORT_SYMBOLs Robert Richter
2008-12-11 17:19 ` [PATCH 0/9] oprofile: port to the new ring buffer Steven Rostedt
2008-12-12  5:57 ` Ingo Molnar
2008-12-16 23:49 ` Andrew Morton
2008-12-17  5:03   ` Pekka Enberg
2008-12-22 23:53 ` Carl Love

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081216172341.GK15411@erda.amd.com \
    --to=robert.richter@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=oprofile-list@lists.sourceforge.net \
    --cc=rostedt@goodmis.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.