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. 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). Nick
Attachment:
rtth.tar.gz
Description: application/gunzip
- Follow-Ups:
- Re: Userspace RCU+rtth hack (was Re: [patch 3/3] radix-tree: RCU lockless readside)
- From: "Paul E. McKenney" <[email protected]>
- Re: Userspace RCU+rtth hack (was Re: [patch 3/3] radix-tree: RCU lockless readside)
- References:
- [patch 0/3] 2.6.17 radix-tree: updates and lockless
- From: Nick Piggin <[email protected]>
- [patch 3/3] radix-tree: RCU lockless readside
- From: Nick Piggin <[email protected]>
- Re: [patch 3/3] radix-tree: RCU lockless readside
- From: "Paul E. McKenney" <[email protected]>
- Re: [patch 3/3] radix-tree: RCU lockless readside
- From: Nick Piggin <[email protected]>
- Re: [patch 3/3] radix-tree: RCU lockless readside
- From: "Paul E. McKenney" <[email protected]>
- [patch 0/3] 2.6.17 radix-tree: updates and lockless
- Prev by Date: Re: [PATCH] stop on cpu lost
- Next by Date: [GIT PATCH] I2C and hwmon patches for 2.6.17
- Previous by thread: Re: [patch 3/3] radix-tree: RCU lockless readside
- Next by thread: Re: Userspace RCU+rtth hack (was Re: [patch 3/3] radix-tree: RCU lockless readside)
- Index(es):
 |