Messages in this thread | | | Subject | Re: [PATCH] TOMOYO: Add garbage collector support. (v3) | From | Peter Zijlstra <> | Date | Wed, 17 Jun 2009 14:28:43 +0200 |
| |
On Wed, 2009-06-17 at 20:19 +0900, Tetsuo Handa wrote: > Paul E. McKenney wrote ( http://lkml.org/lkml/2009/5/27/2 ) : > > I would also recommend the three-part LWN series as a starting point: > > > > # http://lwn.net/Articles/262464/ (What is RCU, Fundamentally?) > > # http://lwn.net/Articles/263130/ (What is RCU's Usage?) > > # http://lwn.net/Articles/264090/ (What is RCU's API?) > I've read these articles. They are very good. > > I came up with an idea that we may be able to implement GC while readers are > permitted to sleep but no read locks are required. > > The idea is to have two counters which hold the number of readers currently > reading the list, one is active and the other is inactive. Reader increments > the currently active counter before starts reading and decrements that counter > after finished reading. GC swaps active counter and inactive counter and waits > for previously active counter's count to become 0 before releasing elements > removed from the list. > Code is shown below. > > atomic_t users_counter[2]; > atomic_t users_counter_idx; > DEFINE_MUTEX(updator_mutex); > DEFINE_MUTEX(gc_mutex);
Sounds like an utter scalability nightmare to me though.
Why not 'simply' use SRCU or always provide an preemptible RCU domain using:
rcu_read_lock_preempt() rcu_read_unlock_preempt() call_rcu_preempt() etc.
along with the already existing
*{,_bh,_sched} variants
That way PREEMPT_RCU would only affect the implementation of the regular RCU implementation, it being either _sched or _preempt.
| |