From: Nick Piggin <npiggin@suse.de>
To: "Paul E. McKenney" <paulmck@us.ibm.com>
Cc: Andrew Morton <akpm@osdl.org>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul McKenney <Paul.McKenney@us.ibm.com>,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: Userspace RCU+rtth hack (was Re: [patch 3/3] radix-tree: RCU lockless readside)
Date: Sat, 24 Jun 2006 12:20:24 +0200 [thread overview]
Message-ID: <20060624102024.GA27865@wotan.suse.de> (raw)
In-Reply-To: <20060622202552.GH1295@us.ibm.com>
On Thu, Jun 22, 2006 at 01:25:53PM -0700, Paul E. McKenney wrote:
> On Thu, Jun 22, 2006 at 08:23:43PM +0200, Nick Piggin wrote:
> >
> > Just out of interest, attached is my userspace RCU implementation
> > and RCU radix-tree concurrent tests for Andrew Morton's radix-tree
> > test harness.
> >
> > The RCU implementation is only 100 lines. Awful performance, of
> > course, but I've stretched the rcu_read_lock/unlock over large
> > periods so that we can get full concurrency at the cost of a
> > bit of memory build up. And it still seems to catch use-after
> > RCU-freed errors pretty easily.
>
> Interesting approach! One caution -- this approach can result in
> RCU callbacks being invoked in the context of either call_rcu() or
> rcu_read_unlock(). In some legitimate uses of RCU, this can result
> in deadlock. See Documentation/RCU/UP.txt for more info.
>
> One solution is to have some other context (perhaps just a separate
> pthread, given that performance is not critical) to invoke the callbacks.
Ah that's true. And I knew that, but it didn't occur to me ;)
>
> Another user-level RCU implementation is available here:
>
> http://www.cs.toronto.edu/~tomhart/perflab/ipdps06.tgz
Interesting, thanks.
> I have a few user-mode implementations myself, but the lawyers won't
> let me release them. :-(
I imagine they're quite a bit faster than my quick hack, too ;)
>
> > Question - our kernel's call_rcu implies a smp_wmb, right? Because
> > that did catch me out initially, because I initially had no barrier
> > to prevent the freeing of the object becoming visible before
> > removal of its last reference becoming visible (fixed by adding
> > smp_wmb() in my call_rcu).
>
> No and yes... The kernel's call_rcu() itself does not have an smp_wmb(),
> but the Classic RCU grace-period mechanism forces a memory barrier on each
> CPU as part of grace-period detection -- which is why rcu_read_lock()
> and rcu_read_unlock() don't need memory barriers. Looks like your need
> for an smp_wmb() in call_rcu() itself is due to the fact that you can
> execute callbacks in the context of the call_rcu() itself.
That makes sense. Thanks for clearing that up.
next prev parent reply other threads:[~2006-06-24 10:20 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-20 14:48 [patch 0/3] 2.6.17 radix-tree: updates and lockless Nick Piggin
2006-06-20 14:48 ` [patch 1/3] radix-tree: direct data Nick Piggin
2006-06-20 14:48 ` [patch 2/3] radix-tree: small Nick Piggin
2006-06-20 14:48 ` [patch 3/3] radix-tree: RCU lockless readside Nick Piggin
2006-06-22 1:49 ` Paul E. McKenney
2006-06-22 15:45 ` Nick Piggin
2006-06-22 16:30 ` Paul E. McKenney
[not found] ` <20060622165551.GB23109@wotan.suse.de>
[not found] ` <20060622174057.GF1295@us.ibm.com>
2006-06-22 18:11 ` Nick Piggin
2006-06-23 7:09 ` Andrew Morton
2006-06-23 8:03 ` Nick Piggin
2006-06-23 8:39 ` Nick Piggin
2006-06-23 8:41 ` Nick Piggin
2006-06-22 18:23 ` Userspace RCU+rtth hack (was Re: [patch 3/3] radix-tree: RCU lockless readside) Nick Piggin
2006-06-22 20:25 ` Paul E. McKenney
2006-06-24 10:20 ` Nick Piggin [this message]
2006-06-24 15:55 ` Joe Seigh
2006-06-20 22:08 ` [patch 0/3] 2.6.17 radix-tree: updates and lockless Benjamin Herrenschmidt
2006-06-20 22:35 ` Andrew Morton
2006-06-20 23:09 ` Benjamin Herrenschmidt
2006-06-20 23:30 ` Andrew Morton
2006-06-20 23:50 ` Benjamin Herrenschmidt
2006-06-21 0:34 ` Christoph Lameter
2006-06-21 0:47 ` Benjamin Herrenschmidt
2006-06-21 1:07 ` Christoph Lameter
2006-06-21 1:33 ` Benjamin Herrenschmidt
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=20060624102024.GA27865@wotan.suse.de \
--to=npiggin@suse.de \
--cc=Paul.McKenney@us.ibm.com \
--cc=akpm@osdl.org \
--cc=benh@kernel.crashing.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@us.ibm.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).